Hi all!

For each new release, we have been cleaning up part of the grenade 'upgrade_*' scripts and start over adding code to it, as we progressively add configuration or other changes to the different components (as seen in patch https://review.openstack.org/#/c/53874/ )

The proposal here is to create some kind of hooks in the 'upgrade_* scripts' that would identify a specific set of release functions, so we can avoid the issue above. That will also be less complex to call grenade for different upgrade versions we need (such as in the gate grenade jobs).

I suggest to create an upgrade directory and Inside it, add an 'upgrade_<release name>' script (as 'upgrade_havana'), which will contain upgrade configuration functions for each component (such as "upgrade_configure_cinder()) . Those functions may hold whatever is needed for the upgrade (policy changes, configuration file changes, etc...).

And for each grenade upgrade script, we use hooks to load the specific set of release upgrade functions we need. The release name contained in the script name can be used as the key to identify which file should be loaded.

I would like to hear your opinion and suggestions to that approach.

Regards

--
Adalberto Medeiros
Linux Technology Center
Openstack and Cloud Development
IBM Brazil
Email: adal...@linux.vnet.ibm.com


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to