Open Stack

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-changes.html
> 
> 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+branch:master+topic:migrator
> 
> 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.html
> http://lists.openstack.org/pipermail/openstack-discuss/2018-December/000856.html
> 
> ## 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/major_upgrade.html)
> - Openstack-Ansible also provide release upgrade mechanisme ( 
> https://docs.openstack.org/openstack-ansible/latest/admin/upgrades/major-upgrades.html)
> - OpenStack fuel also propose specifications to upgrade configuration 
> and release ( 
> https://specs.openstack.org/openstack/fuel-specs/specs/7.0/upgrade-major-openstack-environment.html)
> 
> 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-----
>