Open Stack

 ---- On Sat, 13 Oct 2018 07:05:53 +0900 Matt Riedemann <mriedemos at gmail.com> wrote ---- 
 > The big update this week is version 0.1.0 of oslo.upgradecheck was 
 > released. The documentation along with usage examples can be found here 
 > [1]. A big thanks to Ben Nemec for getting that done since a few 
 > projects were waiting for it.
 > 
 > In other updates, some changes were proposed in other projects [2].
 > 
 > And finally, Lance Bragstad and I had a discussion this week [3] about 
 > the validity of upgrade checks looking for deleted configuration 
 > options. The main scenario I'm thinking about here is FFU where someone 
 > is going from Mitaka to Pike. Let's say a config option was deprecated 
 > in Newton and then removed in Ocata. As the operator is rolling through 
 > from Mitaka to Pike, they might have missed the deprecation signal in 
 > Newton and removal in Ocata. Does that mean we should have upgrade 
 > checks that look at the configuration for deleted options, or options 
 > where the deprecated alias is removed? My thought is that if things will 
 > not work once they get to the target release and restart the service 
 > code, which would definitely impact the upgrade, then checking for those 
 > scenarios is probably OK. If on the other hand the removed options were 
 > just tied to functionality that was removed and are otherwise not 
 > causing any harm then I don't think we need a check for that. It was 
 > noted that oslo.config has a new validation tool [4] so that would take 
 > care of some of this same work if run during upgrades. So I think 
 > whether or not an upgrade check should be looking for config option 
 > removal ultimately depends on the severity of what happens if the manual 
 > intervention to handle that removed option is not performed. That's 
 > pretty broad, but these upgrade checks aren't really set in stone for 
 > what is applied to them. I'd like to get input from others on this, 
 > especially operators and if they would find these types of checks useful.
 > 
 > [1] https://docs.openstack.org/oslo.upgradecheck/latest/
 > [2] https://storyboard.openstack.org/#!/story/2003657
 > [3] 
 > http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2018-10-10.log.html#t2018-10-10T15:17:17
 > [4] 
 > http://lists.openstack.org/pipermail/openstack-dev/2018-October/135688.html

Other point is about policy change and how we should accommodate those in upgrade-checks.

There are below categorization of policy changes:
1. Policy rule name has been changed. 
    Upgrade Impact: If that policy rule is overridden in policy.json then, yes we need to tell this in upgrade-check CLI. If not overridden which means operators depends on policy in code then, it would not impact their upgrade. 
2. Policy rule (deprecated) has been removed
    Upgrade Impact: YES, as it can impact their API access after upgrade.  This needs to be cover in upgrade-checks
3. Default value (including scope) of Policy rule has been changed
    Upgrade Impact: YES, this can change the access level of their API after upgrade. This needs to be cover in upgrade-checks
4. New Policy rule introduced
    Upgrade Impact: YES, same reason. 

 I think policy changes can be added in upgrade checker by checking all the above category because everything will impact upgrade? 

For Example, cinder policy change [1]:

"Add granularity to the volume_extension:volume_type_encryption policy with the addition of distinct actions for create, get, update, and delete:

volume_extension:volume_type_encryption:create
volume_extension:volume_type_encryption:get
volume_extension:volume_type_encryption:update
volume_extension:volume_type_encryption:delete
To address backwards compatibility, the new rules added to the volume_type.py policy file, default to the existing rule, volume_extension:volume_type_encryption, if it is set to a non-default value. "

[1] https://docs.openstack.org/releasenotes/cinder/unreleased.html#upgrade-notes

-gmann

 > 
 > -- 
 > 
 > Thanks,
 > 
 > Matt
 > 
 > _______________________________________________
 > OpenStack-operators mailing list
 > OpenStack-operators at lists.openstack.org
 > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 >