Open Stack

Ben Nemec <openstack at nemebean.com> writes:

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

+1

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

-- 
Doug