Posted by anarcat on September 25, 2009 at 5:52pm
| Project: | Hostmaster (Aegir) |
| Version: | 6.x-0.4-alpha1 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
| Issue tags: | aegir-0.3-hotfix, upgrade path |
Issue Summary
Right now, we tell people to delete the Aegir site from the backend, using provision delete. Unfortunatly, that means that the site detected from the frontend is *not* removed and is basically "rogue" in that it doesn't really reflect the backend anymore: any task performed on the site will fail and it is impossible to disable/delete it, because of #529348: disable can still fail disabling damaged sites.
Not sure what is the right way to do this.
Comments
#1
a better title: this is not a documentation problem, there's a real problem here that doesn't depend only on [#529438].
we're looking at implementing a
hosting migratecommand that would migrate the frontend. this is related with #454312: self-provisionning support.#2
So the work on the git branch (588114_hosting_migrate continues and is now able to upgrade a frontend site. We are considering moving it to the backend...
#3
The branch was merged in mainline, but I'm still maintaining it for the benefit of 0.3 users wanting to upgrade. We're still unsure if this code is going to stay in hosting or migrate (no pun intended) to provision so that upgrades are going to be easier.
In the meantime, people wanting to upgrade from 0.3 to 0.4-cvs should use the attached patch on hosting and follow the instructions (soon to be updated) in UPGRADE.txt in the profile.
#4
#5
Last patch was touching too much stuff and was git-formatted. This one doesn't touch the frontend stuff and just adds the drush commands. Make sure you specify the platform paths exactly as they are in the frontend as path sanitisation is not enforced in 0.3.
#6
So the code was moved to the backend (the provision module) now so the documentation needs to be updated. The above patch is still valid as a hotfix for people that want to upgrade through that, but the prefered way is to upgrade without the patch, through the backend (since you should upgrade the backend first anyways).
#7
this was documented in UPGRADE.txt
#8
Automatically closed -- issue fixed for 2 weeks with no activity.