improve trove upgrade capability by abstracting pre_upgrade and post_upgrade
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack DBaaS (Trove) |
New
|
Medium
|
Doug Shelley |
Bug Description
From comment in review: https:/
pre_upgrade and post_upgrade as shown in this implementation work (I've extended them for SQLServer for shits and giggles) but I think they present a heavy weight approach to doing things.
in this model, you need to implement pre_upgrade and post_upgrade for each datastore that must support upgrade. I think this is less than ideal.
I would much rather pre_upgrade and post_upgrade be driven by configuration in the datastore identifying where the implementation stores stuff (so mysql would merely identify /etc/my.cnf, and a set of files or directories) and a common implementation would make sure that these were preserved across the upgrade.
Each datastore would then merely have to identify the nuggets, rather than provide the implementation for moving said nuggets.
I think this is something that can be improved later, I've logged a bug for this.