Ticket #8802 (closed PLIP: fixed)
Move our upgrade / migration infrastructure to GenericSetup
Reported by: | hannosch | Owned by: | davisagli |
---|---|---|---|
Priority: | minor | Milestone: | 4.0 |
Component: | Upgrade/Migration | Version: | |
Keywords: | Cc: | dukebody, esteele, plip-advisories@… |
Description (last modified by davisagli) (diff)
Overview
GenericSetup is used for configuring new sites and managing their state. It also supports so called upgrade steps, which can be used to upgrade GS profiles from one version to the next.
The upgrade machinery of Plone was so far based on CMFPlone.migration which contained a completely custom implementation for Plone itself. This machinery was not usable for add-on products.
We should instead use upgrade profiles from GenericSetup to manage our own upgrade.
Implementation / Deliverables
I plan to make use of the work Hanno has done toward this end in Plone trunk + plone.app.upgrade. This accomplishes the following:
- Moves the migration code to a separate package called plone.app.upgrade, so that the Plone egg doesn't have to depend on things that are only required for migrating.
- Registers migration actions as GenericSetup upgrade steps, and turns the migration tool into a thin wrapper around GS.
Actually on trunk Hanno has gone as far as removing the migration tool entirely, but that is beyond the ambition of this PLIP which is aimed at Plone 4. Also, plone.app.upgrade has removed support for migrations from pre-3.0 Plones up to 3.0, and I intend to replace the support for migrations from 2.1 and 2.5, as these versions are still commonly found in the wild.
Assumptions
Getting rid of the migration tool completely and relying on GenericSetup's UI only is too risky for 4.0 from both a technical and user experience perspective.
Progress
Hanno has already implemented a large part of this on Plone trunk + plone.app.upgrade.
All existing migration steps, tests and the entire machinery have been rewritten as upgrade steps inside a new package called plone.app.upgrade. The old CMFPlone.migrations subpackage was removed. As noted above, though, I still need to make sure that migrations from pre-3.0 are moved to the new format.
Participants
David Glick
Change History
comment:4 Changed 7 years ago by davisagli
- Description modified (diff)
- Milestone changed from 5.0 to 4.0
Added to Hanno's description and assigned to 4.0
comment:6 Changed 7 years ago by hannosch
The removal of the migration tool as done on trunk, doesn't mean I envisioned people to use the portal_setup tool to do the migrations. I think this needs a somewhat stand-alone browser view with a non-scary UI. The current migration tool ZMI screens aren't exactly user friendly either.
One problem with the Plone upgrade screen itself, is that it must be usable with only a very minimal wiring into the rest of the system for major upgrades. After a major upgrade like Plone 3 or Plone 4, it is expected that none of the normal Plone UI works (missing viewlets, portlet managers, missing utility registration, broken objects, ...).
For the minor upgrades and certainly the maintenance upgrades a UI that integrates into the Plone control panel would be much nicer.
Once such a new UI is written, the migration tool looses its purpose. It's one of the tools that doesn't store any data, but merely exists to make functions available to the skin layer scripts and templates.
comment:8 Changed 7 years ago by erikrose
- Owner davisagli deleted
Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)
comment:10 Changed 7 years ago by davisagli
- Owner set to davisagli
I abstain from voting as this is my PLIP.
comment:11 Changed 7 years ago by MatthewWilkes
FWT Vote: +1
comment:12 Changed 7 years ago by rossp
My FWT vote is +1 though I would like to see more discussion of the risks.
comment:13 Changed 7 years ago by raphael
FWT vote: +1 - yes, please
comment:14 Changed 7 years ago by calvinhp
FWT Vote: +1 with the caveat that I would like to see a friendly site setup UI included in the proposal as the GS UI isn't meant for "normal" humans.
comment:15 Changed 7 years ago by erikrose
GS currently runs into problems in real-life situations where things gets removed from sites without being properly uninstalled, refusing to install further products until the improperly removed products are dug up and reinstalled ( https://weblion.psu.edu/trac/weblion/wiki/GenericSetup#Troubleshooting). GS makes me a little nervous. Could the proposed code run into similar problems? I vote -1 until the risks are enumerated.
comment:16 Changed 7 years ago by esteele
Approved by FWT vote.
comment:17 Changed 7 years ago by davisagli
- Status changed from new to assigned
ErikRose: GS profiles are already used to accomplish certain steps of our existing migrations, so I don't think the implementation of this PLIP introduces a big new risk in that regard. 90% this change is about how we determine what actions need to run for an upgrade between two particular versions, not about the actual running of those actions.
comment:18 Changed 7 years ago by davisagli
comment:19 Changed 7 years ago by davisagli
comment:20 Changed 7 years ago by esteele
Your PLIP has been reviewed by the Framework team. Feel free to discuss any suggested changes either here in the PLIP ticket or on the mailing lists. Final deadline for this PLIP is set for September 30.
comment:21 Changed 6 years ago by esteele
Please assist the doc team in creating/updating documentation relating to this PLIP. See #9619.
comment:22 Changed 6 years ago by esteele
- Status changed from assigned to closed
- Resolution set to fixed