Open Stack

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