Re: [openstack-dev] [nova][stable] What nova needs to get to newton end of life
On 12/19/2017 8:16 PM, Matt Riedemann wrote: 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: https://bugs.launchpad.net/nova/+bug/1739318 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 stable/pike. Anyway, it's late and I wanted to bring these up so people can ponder. I have backports proposed for the fix with the online data migration regression introduced in Newton: https://review.openstack.org/#/q/I214a44f0eee7d90be5cd89f32f6e0017b19a3fd6 I've also updated the final newton release patch to depend on that fix merging in stable/newton. -- 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
Re: [openstack-dev] [nova][stable] What nova needs to get to newton end of life
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-requ...@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: https://bugs.launchpad.net/nova/+bug/1739318 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 stable/pike. Anyway, it's late and I wanted to bring these up so people can ponder. -- 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
Re: [openstack-dev] [nova][stable] What nova needs to get to newton end of life
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 -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76 signature.asc Description: PGP signature __ 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
[openstack-dev] [nova][stable] What nova needs to get to newton end of life
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. 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 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. -- 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
