---- On Sat, 13 Oct 2018 07:05:53 +0900 Matt Riedemann <mriede...@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-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
