This module is leaning on Aegir. It for now adds fields and functionality to the platform-add form. In the future it should make adding modules to drupal installations as well.

Web frontend of aegir:
1) Apply the settings. A folder is generated to store the future platforms. The final destination for the platforms is verified.
2) Options are added to the form to let the system download the platform from a specific location by means of CURL, or The platform is uploaded from the client's machine.
3) Information about the upload is stored in the database.

Drush backend of aegir
1) drush_h8rdeployment_pre_hosting_task hooks into the pre-hosting-task to catch a pre-hosting-provision event.
2) The uploaded drupal platform is extracted using 7zip (expected to be installed at the server)
3) Aegir does the rest as normal (as if the platform was uploaded via ssh)

Description of the files:
/*.drush - hook into the drush provision task
/*.info - ...
/*.install - create a table in the database to store extra information at nodes affected by the module
/*.module - hook into the web frontend of aegir
/include/functions.inc - some functions that are used by drush, leaning against system commands
/include/platform.php - Extend the platform add form
/include/settings.php - Provide a settings page for the module
/include/WebBrowser.php - Some php-cooking about downloading a platform to the webserver. Actualy a very usable php-webbrowser based on CURL.

Comments

mermentau’s picture

Status: Needs review » Needs work

You will need a link to your sandbox project for review to begin.

omega8cc’s picture

I see your sandbox is here: http://drupal.org/sandbox/erlendoos/1076482

Two issues so far (I will also try the module with Aegir):

1. The project name should be changed to hosting_deployment, see why: http://hefring.mig5.net/bot/log/aegir/2011-05-03#T67571

2. You need to follow Drupal coding standards, now you have tabs and 4 spaces instead of 2, see: http://drupal.org/coding-standards#indenting

Thanks for your contribution!

omega8cc’s picture

Another important issue:

It is probably a bad idea to require non-standard archive formats and system level dependency like 7zip. It is always better to stay compatible with existing and already planned features in Aegir and Drush to avoid possible conflicts and code duplication in the future.

Relevant links for more information:

http://drupal.org/node/1138882
http://groups.drupal.org/node/106754

erlendoos’s picture

@omega8cc:

It is a way to convert archives without bothering about the archive type. 7zip had the most straightforward implementation of a commandline interface as far as I know.

What method would you recommend to get this job done if not by using 7zip?

omega8cc’s picture

@erlendoos

While using 7zip can be very handy for the reason you mentioned, you shouldn't make it a requirement, because it is not installed on systems like Debian or Ubuntu by default. It could be used only when present, with default fallback to standard format used in Aegir, which is tar/gzip archive, so adding simple if/else logic for /usr/bin/7za existence could make your module easier to adopt.

But it is just my opinion, and not any kind of requirement in the project review process, while other issues are important to pass the review testing.

omega8cc’s picture

Most people will use tar.gz or .zip archives probably, and tar/gzip is present by default on any Linux distro, and unzip is already an Aegir dependency, so it is safe to require the archive to be in tar/gzip or zip format, I think. And it is better for further/future compatibility with site archive formats, when introduced in Drush and Aegir. But again, it is only a suggestion.

erlendoos’s picture

I choose 7za for it does not depend on the file extension. That is not a requirement, but a very nice feature of this app. I'll implement the hook_requirements to see if the application is installed correctly.

The audience of this module would be system administrators. To install Aegir one needs root access to the server. I trust that users of this module are able to install 7za.

omega8cc’s picture

I think it is fine now.

There is still an issue I mentioned in #2 above - the project name shouldn't use Aegir profile name (hostmaster), and, as requested by Aegir lead developer anarcat for another contrib work, it should use hosting_ prefix instead.

erlendoos’s picture

The new name for the project: Hosting deploy

omega8cc’s picture

Title: Hostmaster deployment » Hosting deploy

Thank you for the changes made so far.

Your sandbox contains now a LICENSE.txt for GPL version 3. LICENSE.txt files are automatically added for you by the package handler, so this should be removed, and you must be willing to license your project under version 2 and later of the GPL to host your project at drupal.org. We hope this isn't a problem for you.

omega8cc’s picture

One more thing: the $Id$ lines should be removed, we don't use them after migration to Git.

omega8cc’s picture

This one is probably a bug introduced after renaming the project: you are creating a table hosting_deploy_nodedata on install, but you have still deployment_nodedata table used in function set_deployment_data() and function get_deployment_data() etc.

erlendoos’s picture

Solved, among some other problems that I found during the latest test-round.
What is next?

omega8cc’s picture

Status: Needs work » Needs review

There is still "GNU General Public Licence v3" in the code, while GPL v2 is required to pass the review process. For more information please see: http://drupal.org/node/539608

I will set it back to "needs review" now, so others could also help with the code review, before admins will grant you permissions to promote the project.

Thank you for your contribution, patience and good co-operation.

erlendoos’s picture

Component: new project application » module

How serious is the part where php-doc is described?

memtkmcc’s picture

I tried your module with Aegir and I see some missing stuff here - nothing critical, but UX related:

1. Aegir extensions should be visible at /admin/hosting/features
2. The settings for extensions should be visible at /admin/hosting/settings
3. The Add platform screen is a bit confusing: https://skitch.com/omega8cc/r9pge/create-platform-aegir-hosting-system-b...

Maybe you could add there the info that the "Download Codebase:" field is to enter the URL to the remote file?

I tried it with some remote URLs and it downloaded the platform but then failed with error:

Could not create tempdir (1): /data/disk/o1/platforms/stream-test2.tmp

Not sure why it fails, permissions are correct there.

Also when I used the "Upload Codebase:" option, it failed with the same error.

memtkmcc’s picture

Oh, I forgot I tried it on a fresh vps, without 7za installed!

memtkmcc’s picture

Status: Needs review » Reviewed & tested by the community

OK, it works after I installed required p7zip-full, so I believe we can change the status to RTBC and then wait for admins approval/opinion.

erlendoos’s picture

I could provide a way to show that a requirement is missing more clear, perhaps in the form after adding a platoform
I'll change the way settings are presented.

Thanks for reviewing and testing!

omega8cc’s picture

@erlendoos

This could be probably a feature request, but I will post it here anyway.

The Add platform form could be improved, since your module replaces/hides default field allowing you to specify the path to the platform, which breaks both makefile method and standard (manual) method.

I see two options here: either hide also the makefile field when your module is enabled, or leave the standard path field visible (even with the cost of extra confusion).

Another option could be to introduce some simplified interface there, with radio buttons dynamically modifying the form to display/choose only one of three available methods at the time: manual, makefile or upload/fetch (download).

What do you think?

erlendoos’s picture

You are right. The current situation breaks the makefile functionality. I did not realize that until recently, I red something about drush make. It looks a bit like what I wanted to accomplish. Only, this module is a bit more straight forward (IMHO).

The fields can be moved to a field-group. (hidden by default)

erlendoos’s picture

Title: Hosting deploy » Hosting upload
mlncn’s picture

Status: Reviewed & tested by the community » Fixed

Thank you erlendoos for your work and thank you octopus and especially omega8cc for your reviews.

Congratulations, erlendoos!  You can now promote sandbox projects to full status ones. You may want to look at Drush Make a bit more thoroughly for possible integration before promoting this one.  When you would like further review for any project please do ask at http://groups.drupal.org/peer-review/requests

Further issues introduced here and new ones can be filed on your project issue queue.  Thank you for this contribution and i look forward to seeing its refinement and development and your continued involvement in Drupal!

benjamin, agaric

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.