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-----