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
Comment #1
mermentau commentedYou will need a link to your sandbox project for review to begin.
Comment #2
omega8cc commentedI 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!
Comment #3
omega8cc commentedAnother 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
Comment #4
erlendoos commented@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?
Comment #5
omega8cc commented@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.
Comment #6
omega8cc commentedMost 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.
Comment #7
erlendoos commentedI 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.
Comment #8
omega8cc commentedI 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.
Comment #9
erlendoos commentedThe new name for the project: Hosting deploy
Comment #10
omega8cc commentedThank 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.
Comment #11
omega8cc commentedOne more thing: the
$Id$lines should be removed, we don't use them after migration to Git.Comment #12
omega8cc commentedThis one is probably a bug introduced after renaming the project: you are creating a table
hosting_deploy_nodedataon install, but you have stilldeployment_nodedatatable used infunction set_deployment_data()andfunction get_deployment_data()etc.Comment #13
erlendoos commentedSolved, among some other problems that I found during the latest test-round.
What is next?
Comment #14
omega8cc commentedThere 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.
Comment #15
erlendoos commentedHow serious is the part where php-doc is described?
Comment #16
memtkmcc commentedI 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.tmpNot sure why it fails, permissions are correct there.
Also when I used the "Upload Codebase:" option, it failed with the same error.
Comment #17
memtkmcc commentedOh, I forgot I tried it on a fresh vps, without 7za installed!
Comment #18
memtkmcc commentedOK, 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.
Comment #19
erlendoos commentedI 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!
Comment #20
omega8cc commented@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?
Comment #21
erlendoos commentedYou 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)
Comment #22
erlendoos commentedComment #23
mlncn commentedThank 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