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
--
Thanks,
Matt
__________________________________________________________________________
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
