On 26 January 2017 at 14:14, Ed Leafe <e...@leafe.com> wrote: > On Jan 26, 2017, at 7:50 AM, Sylvain Bauza <sba...@redhat.com> wrote: >> >> That's where I think we have another problem, which is bigger than the >> corner case you mentioned above : when upgrading from Newton to Ocata, >> we said that all Newton computes have be upgraded to the latest point >> release. Great. But we forgot to identify that it would also require to >> *modify* their nova.conf so they would be able to call the placement API. >> >> That looks to me more than just a rolling upgrade mechanism. In theory, >> a rolling upgrade process accepts that N-1 versioned computes can talk >> to N versioned other services. That doesn't imply a necessary >> configuration change (except the upgrade_levels flag) on the computes to >> achieve that, right? >> >> http://docs.openstack.org/developer/nova/upgrade.html > > Reading that page: "At this point, you must also ensure you update the > configuration, to stop using any deprecated features or options, and perform > any required work to transition to alternative features.” > > So yes, "updating your configuration” is an expected action. I’m not sure why > this is so alarming.
We did make this promise: https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html#requirements Its bending that configuration requirement a little bit. That requirement was originally added at the direct request of operators. Now there is a need to tidy up your configuration after completing the upgrade to N+1 before upgrading to N+2, but I believe that was assumed to happen at the end of the N+1 upgrade, using the N+1 release notes. The idea being warning messages in the logs etc, would help that all get fixed before attempting the next upgrade. But I agree thats not what the docs are currently saying. Thanks, John __________________________________________________________________________ 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
