[openstack-dev] [nova][stable] What nova needs to get to newton end of life

Matt Riedemann mriedemos at gmail.com
Wed Dec 20 02:16:00 UTC 2017

On 12/15/2017 4:50 AM, Lee Yarwood wrote:
> On 14-12-17 09:15:18, Matt Riedemann wrote:
>> I'm not sure how many other projects still have an active stable/newton
>> branch, but I know nova is one of them.
>> At this point, these are I think the things that need to get done to end of
>> life the newton branch for nova:
>> 1. We have a set of existing stable/newton backports that need to get
>> merged:
>> https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/newton
>> 3 of those are related to a CVE errata, and the other is an API regression
>> introduced in Newton (trivial low-risk fix).
>> Those can't merge until the corresponding Ocata backports are merged first.
>> I'll start pinging people for reviews on the Ocata backports.
> The Ocata changes have mereged and the remaining Newton changes are
> approved. I'll keep an eye on these during the day to ensure they land.
>> 2. Fix and backport https://bugs.launchpad.net/nova/+bug/1738094
>> This came up just yesterday but it's an upgrade impact introduced in Newton
>> so while we have the branch available I think we should get a fix there
>> before EOL. There are going to be at least two fixes for this bug:
>> a) Don't store all of the instance group (members and policies) in the
>> request_specs table. I think this is a correct fix but I also think because
>> of how instance groups and request spec code tends to surprise you with
>> funny bugs in funny ways, it's high risk to backport this to newton. Dan has
>> a patch started though: https://review.openstack.org/#/c/527799/3
> This merged into master so I went ahead and posted the stable backports:
> https://review.openstack.org/#/q/topic:bug/1738094+(status:open+OR+status:merged)
>> b) Alter the request_specs.spec column from TEXT to MEDIUMTEXT, just like
>> the build_requests.instance column was increased for similar reasons
>> (instance.user_data alone is a MEDIUMTEXT column). This is a straight
>> forward schema migration and I think is low risk to backport all the way to
>> Newton.
> FWIW this is the master change - https://review.openstack.org/#/c/528012/
> Cheers,
> Lee
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

A quick update here.

There are no outstanding newton backports proposed. I put up the final 
release request earlier today.

However, tonight mnaser reported a bug which impacts Pike+ because of a 
regression introduced in an online data migration from Newton:


I have two patches up for this bug so far. One fixes the actual 
migration, which would help anyone that hasn't run it yet (people 
upgrading from mitaka or older). The other works around the bug for 
anyone that has run the migration and is now hitting the side effect in 
Pike or Queens.

At this point, I'm not sure if we should hold newton up for the first 
fix. It's super simple though, and is low risk to backport.

On the other hand, we have the workaround which we can also backport to 

Anyway, it's late and I wanted to bring these up so people can ponder.




More information about the OpenStack-dev mailing list