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.I think this is rather a serious issue, as it leads to data loss.
It should be obvious that we cannot use the "spoke" model for sites when thinking about the whole archticture with remotes. Because at _least_ the database and the files will be more up-to-date on the remote in 100% of all cases, we cannot think about "push from the master" in this cases - and we dont.
But it seems like we dont do this for the sites/domain/modules and themes folder.
When you:
- put a theme into the domain/themes folder on the remote
- you migrate that site ( on the same remote or somewhere else )
You end up:
- losing that theme
Thats pretty bad. Iam not sure this can be avoided when verifing before migrating ( which i did not do ), but if, we _must_ do this automatically before migrating. I would advice to deal with the "site/domain" folder the "spoke" model way, but "reverse", so the "remote" is always the master. Lets call this folder the "users playground":
- he changes the database without askign the master
- he changes the files without asking the master
- he adds themes for himself or whatever
Iam sorry if this issue is again mixing up an issue and a feature request, but i think to proper fix the bug, we should "extend" the default behavior. What do you think?
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | syncfix.patch | 908 bytes | EugenMayer |
Comments
Comment #1
EugenMayer CreditAttribution: EugenMayer commentedJust for an update, on verify, the folder does not get synced, so the modules / themes folder would get lost in any case. Marking this as critical for now, as it really could harm pages as
- both folders are created when the site folder is "initiated"
- so people are invited to use it
As far as i see, this issue would not happen when you:
- dont use remote
- when you migrate from the aegir master to a remote
but it will happen when you clone / migrate:
- from a remote to a remote
Comment #2
EugenMayer CreditAttribution: EugenMayer commentedWell pretty simply, themes modules and libraries are never synced back to the master, only files ( platform/backup.provision.inc ), therefore those stuff is lost when its a remote. Patch incoming, also see http://drupal.org/node/1080588
Patch incoming, take cover :)
Comment #3
EugenMayer CreditAttribution: EugenMayer commentedShould be it. Yet iam not sure what about verify. It seems (code wise) that the site/domain folder is not synced from master to remote during verify.
Comment #4
EugenMayer CreditAttribution: EugenMayer commentedfor the record, close http://drupal.org/node/1080588 if this one gets fixed
Comment #5
EugenMayer CreditAttribution: EugenMayer commentedconfirming this patch fixes it for migrate / clone. Verify does not touch anything, as it does not sync ( so it also does not need to be patched ).
For me, its RTBC
Comment #6
bwood CreditAttribution: bwood commentedSounds like you are challenging some design decisions re the hub-spoke model?
If all changes are done on the hostmaster server's platform then verify will rsync them out to the remote webservers. You probably don't want developer logging in to the hostmaster server, right? I solved this with a version control (subversion) workflow. Developers checkin changes to the site to version control, a cron job periodically loops over 'drush sa' attempting to do 'svn up' on the working copy directories that live on the hostmaster server's platforms. When 'svn up' results in new data, the script 1) emails svn up output to the client_email 2) kicks off verify which syncs the site to the remote webserver.
Comment #7
EugenMayer CreditAttribution: EugenMayer commented@6: no i dont challange it.
Or are you "spoking" files? no you arent, because they are changed on the remote. Are you "spoking" DB? No, its changed on the remote. Same for privates.
So the spoke model does not mean everything comes for the master. I fine with it that "code" is that way, so platforms are alway in sync. VHOST/ Platfom configurations, also global.inc.
I see that modules / themes are a mixup here, due to the possibility that they exists in sites/all. But i just take it very simple, everything in sites/$site/ is _site_ specific, not platform specific:
- files / private files
- DB (database.sql..)
- modules / themes
That is btw the only way to have something "site specific". Call it "site level overrides". And those stuff you want to get migrated with the site (or cloned) no matter what platform. And a theme is a _perfect_ example here. It would simply not work any other way.
Comment #8
EugenMayer CreditAttribution: EugenMayer commentedSee http://drupal.org/node/1083366 for an additional fix during the verify process
Comment #9
anarcat CreditAttribution: anarcat commentedI agree it is inconsistent to fetch "files" but not "private" from the remote server. modules/themes/libs are probably the same, and local.settings.php...
I wonder if we shouldn't use an exclude pattern instead...
fix committed, thanks.