Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Basically, I want the ability to set the access permissions on a new platform as being the same as those on an existing one. This would allow us to more easily manage permissions during site migrations.
This could either be triggered in some why by site migrations, platform creation or be a new task.
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | provision-906936-13-Clone_platform.patch | 5.35 KB | helmo |
| #10 | hosting-906936-10-Clone_platform.patch | 6.92 KB | helmo |
| #10 | provision-906936-10-Clone_platform.patch | 5.45 KB | helmo |
| #8 | provision-906936-8-Clone_platform.patch | 5.16 KB | helmo |
| #8 | hosting-906936-8-Clone_platform.patch | 2.75 KB | helmo |
Comments
Comment #1
helmo CreditAttribution: helmo commentedIn my opinion it would make most sense to include this in platform creation.
It would be nice to go to an existing platform and create a task to create a new platform version. Especially in cases where a makefile is used for the platform this could come in handy.
I'm not sure if we could just copy the existing platform tree in case no platform files exist for the new platform and a makefile is not present either.
Comment #2
Robin Millette CreditAttribution: Robin Millette commentedsubbing
Comment #3
Steven Jones CreditAttribution: Steven Jones commentedChanging the title to reflect what's wanted here.
Comment #4
helmo CreditAttribution: helmo commentedJust thinking out loud here about how this would look....
Create new platform task type in hostmaster,
* called "clone platform" or just "clone" if that doesn't lead to confusion.
* type is available when a makefile is specified for the platform
* Create new platform node based on makefile
* Path and name should be derived from a predetermined scheme
*
<distribution>-<core version>-<distribution-version>-<build tag/code>e.g. openatrium-6.x-1.0-aegir1
* Other platform properties should be copied, autonomously if possible via hooks otherwise (e.g. in hosting_profile_roles)
Pro: this should be possible without changes to provision
Con: does not work for users who don't use makefiles
Comment #5
anarcat CreditAttribution: anarcat commentedi like having provision-clone also work on platforms.
Comment #6
Steven Jones CreditAttribution: Steven Jones commentedComment #7
Steven Jones CreditAttribution: Steven Jones commentedtagging
Comment #8
helmo CreditAttribution: helmo commentedAn addition to provision would be nice here.
It should:
* copy the platform tree
** excluding the sites/* folders, but still copy sites/all and sites/default
Advantages:
* work for platforms without a makefile
* Prevent having updated version in the platform clone
* Allow for cloning a platform to a different server
Notes:
* It's tempting to use hardlinks, but screwing up is easy. As applying a patch could change both platforms
I'm hacking on some prototype code for this.... see patches.
I've neglected to indent some pieces to keep the diff clean.
Comment #9
anarcat CreditAttribution: anarcat commentedthat's cool, marking proper status.
Comment #10
helmo CreditAttribution: helmo commentedI've worked a bit more on this.
* UI now works from hostmaster site
* compatibility with hosting_pathauto
* Selecting a target server
A few todo's remain open, comments would be appreciated.
Comment #11
helmo CreditAttribution: helmo commentedSome open questions:
* Is it ok to handle sites and platforms in provision-clone, or should these be split?
* I manually call rsync or should we use drush_core_call_rsync()
* Can I run
provision_backend_invoke('@hostmaster', 'hosting-import', array($platform_alias));from drush_provision_drupal_provision_clone in provision or from the hosting module via a hook drush_provision_drupal_post_provision_cloneComment #12
Anonymous (not verified) CreditAttribution: Anonymous commentedHi helmo,
Thanks for your work on this!
Answers to your questions:
1) It's ok to have it all in platform/clone.provision.inc if that's what you mean. We do the same with provision-delete and provision-verify.
2) I think it would be best to try and be consistent with what we do in verify, e.g when rsyncing to remote hosts.. at least in terms of what function we call. Note that the provision.context.inc uses drush_core_call_rsync() with an array of options, which might be nicer, because drush_core_call_rsync seems to accept 'exclude-sites' as an argument (see drush rsync --help). In general I am keen to rely on Drush's built-in support for such things.
3) This would be better as a post hook in the hosting_clone feature, and it could just call the hosting_import function directly in that case (I think? Presuming we can get the new platform alias name back from the provision context.. we should be able to because we import sites in a post hook in frontend too)
A couple notes on the patches:
1) We have a couple of print_r() and commented out test code in both hosting and provision patches.. and possibly whitespace as I can see modified lines where the code isn't actually changing
2) Typo 'platfomr' in the provision patch
These are just cosmetic at a first glance - I will try to test the actual functionality of the patches soon.
Thanks again!
Comment #13
helmo CreditAttribution: helmo commentedI've now updated the patch to use drush_core_rsync to make use of the exclude-sites option.
This does depend a bit on Drush 5, and some of it's issues #1596916: include-vcs option gets passed directly to rsync
I've removed the debug code.
Just the provision patch at the moment.
Comment #14
anarcat CreditAttribution: anarcat commentedplease mark proper status.
Comment #15
helmo CreditAttribution: helmo commentedWell, although any review is welcome I left it at needs work because I only updated the provision side, the hosting patch still needs to be updated. I just ran out of time.
Comment #16
Robin Millette CreditAttribution: Robin Millette commentedComment #17
ergonlogicNew features need to be implemented in Aegir 3.x, then we can consider back-porting to Aegir 2.x.