I'll reiterate what I said in the meeting for the broader audience: I'm unclear how much need there is for a tool of this nature. As you mentioned, deployment tools all have config management bits already that will be handling updates and upgrade. The only instance where I could see this being used is if someone were writing their configs by hand, and I'm skeptical that happens very often with a system as complex as OpenStack. When there was a team that was interested in implementing and using this I was fine with adding it, but if the people who wanted the tool are no longer around then we have no one to maintain it or assist with the adoption of some of the new features it adds. Given my concerns above, I don't want to add a large feature that the Oslo team will then have to maintain. We really don't have the capacity to be taking on lower priority work, especially if there's no one saying "yeah, I'll use that". I've left a comment on the first patch in the series[1] (and marked it WIP) to ask if there is still interest in this feature. Of course, if anyone reading this has interest please feel free to indicate that as well. It's unfortunate because I and a number of the other Oslo contributors have put a significant amount of time into the design and implementation of this tool, but if no one's going to use it then I'd rather cut our losses than continue pouring time into it. Thanks. -Ben 1: https://review.openstack.org/#/c/526314 On 12/18/18 9:07 AM, Herve Beraud wrote:
Hey teams,
## Summary
The main goal of this thread is to coordinate teams to adopt the oslo realease migrator tools and raise prior on this topics.
## History
During the openstack submit in 2017 at Sydney a team from the Fujitsu company propose a talk about how to make fast forward upgrade from an openstack release to an another, and present the state of art of the configuration migrator inside openstack and the tools availables to do that.
This team describe that for now, we have oslo.config generator tool to show deprecated options in newer release but they are still lacking some mapping configurations.
After that the same team propose oslo.config specifications to improve migrators.
Where specifications was designed by the following reviews: - https://review.openstack.org/#/c/520043/ - https://review.openstack.org/#/c/526314/ - https://review.openstack.org/#/c/526261/
The main goal of the proposed changes in these specs is to handle configuration changes over releases: - https://specs.openstack.org/openstack/oslo-specs/specs/rocky/handle-config-c...
These specifications describe that there should be some helper in oslo.config for automatically adopt new changes and help users manage their configuration files easily.
Scenario: Below is the proposed workflow that users can perform on old system to generate new configuration for preparing upgrading to new release: +--------------+ Old configuration +--------> | (N-1 release) | Oslo | | Config +-------> New configuration Namespaces +--------> Migrator | (N release) | | +--------------+ Running on new environment
Since these specifications was validated, some patches was submitted by the Fujitsu team to implement them: https://review.openstack.org/#/q/status:open+project:openstack/oslo.config+b...
Details: - handle config mapping changes ( https://review.openstack.org/526314) - update valid value in choice list for the opt ( https://review.openstack.org/603060) - update 'sample_default' instead of 'default' when migrating ( https://review.openstack.org/606211) - use difflib to report mismatches in migrator tests ( https://review.openstack.org/606210) - replace loop with dictionary lookup ( https://review.openstack.org/606209) - replace 'upgrade_value' with 'convert_on_upgrade' ( https://review.openstack.org/606207)
Since these changes was proposed some peoples from the Fujitsu seems to left the company and also seems to abandon this topic.
During the last oslo meeting I had added this topic to the meeting agenda to bring up this topic and to help us to move forward on it. http://eavesdrop.openstack.org/meetings/oslo/2018/oslo.2018-12-17-15.00.log.... http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000856....
## Current state
Some reviews was validated but some others need to be recovered due to the lack of response about the original authors.
I've submit some patches on reviews to help us to move on it.
I've made some reviews based on the last comments and based on the asked changes but now we need someone with an deeply knowledge on oslo.config to validate the works.
## Others aspects
Some tools like puppet/ansible/chef etc... already in use in openstack can already handle migrators/upgrades and manage config changes.
- Do we need to introduce an another tool like this one to do this job? - How many people are manually writing OpenStack configs in the first place? - Does it make sense to implement these changes?
## List of similar features on others projects
- Tripleo provide a major release upgrade mechanisme ( https://docs.openstack.org/tripleo-docs/latest/upgrade/developer/upgrades/ma...) - Openstack-Ansible also provide release upgrade mechanisme ( https://docs.openstack.org/openstack-ansible/latest/admin/upgrades/major-upg...) - OpenStack fuel also propose specifications to upgrade configuration and release ( https://specs.openstack.org/openstack/fuel-specs/specs/7.0/upgrade-major-ope...)
This wiki can be useful to obtain the big picture of the release upgrade management in openstack ( https://wiki.openstack.org/wiki/Upgrade-with-minimal-downtime)
I surely forgot some tools and alternatives, if you see something that can be added here do not hesitate to reply to add it.
## Conclusion
I bring up this topic to open a debate so do not hesitate react on this topic by responding at this thread to help us to have a better big picture to make the best choice.
Thanks folks.
Best regards.
-- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE-----
wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----