improve trove upgrade capability by abstracting pre_upgrade and post_upgrade

Bug #1621887 reported by Amrith Kumar
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack DBaaS (Trove)
New
Medium
Doug Shelley

Bug Description

From comment in review: https://review.openstack.org/#/c/326064/10/trove/guestagent/datastore/mysql_common/manager.py

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.