<div dir="ltr">It is not just about BVT. I'd suggest to monitor situation overall, including failures of system tests [1]. If we see regressions there, or some test cases will start flapping (what is even worse), then we'd have to revert back to CentOS 7.1.<div><br></div><div>[1] <a href="https://github.com/openstack/fuel-qa">https://github.com/openstack/fuel-qa</a></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 2, 2016 at 10:16 AM Dmitry Borodaenko <<a href="mailto:dborodaenko@mirantis.com">dborodaenko@mirantis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree with Mike's concerns, and propose to make these limitations (4<br>
weeks before FF for OS upgrades, 2 weeks for upgrades of key<br>
dependencies -- RabbitMQ, MCollective, Puppet, MySQL, PostgreSQL,<br>
anything else?) official for 10.0/Newton.<br>
<br>
For 9.0/Mitaka, it is too late to impose them, so we just have to be<br>
very careful and conservative with this upgrade. First of all, we need<br>
to have a green BVT before and after switching to the CentOS 7.2 repo<br>
snapshot, so while I approved the spec, we can't move forward with this<br>
until BVT is green again, and right now it's red:<br>
<br>
<a href="https://ci.fuel-infra.org/job/9.0.fuel_community.ubuntu.bvt_2/" rel="noreferrer" target="_blank">https://ci.fuel-infra.org/job/9.0.fuel_community.ubuntu.bvt_2/</a><br>
<br>
If we get it back to green but it becomes red after the upgrade, you<br>
must switch back to CentOS 7.1 *immediately*. If you are able to stick<br>
to this plan, there is still time to complete the transition today<br>
without requiring an FFE.<br>
<br>
--<br>
Dmitry Borodaenko<br>
<br>
<br>
On Wed, Mar 02, 2016 at 05:53:53PM +0000, Mike Scherbakov wrote:<br>
> Formally, we can merge it today. Historically, every update of OS caused us<br>
> instability for some time: from days to a couple of month.<br>
> Taking this into account and number of other exceptions requested, overall<br>
> stability of code, my opinion would be to postpone this to 10.0.<br>
><br>
> Also, I'd suggest to change the process, and have freeze date for all OS<br>
> updates no later than a month before official FF date. This will give us<br>
> time to stabilize, and ensure that base on which all new code is being<br>
> developed is stable when approaching FF.<br>
><br>
> I'd also propose to have freeze for major upgrades of 3rd party packages no<br>
> later than 2 weeks before FF, which Fuel depends heavily upon. For<br>
> instance, such will include RabbitMQ, MCollective, Puppet.<br>
><br>
> On Wed, Mar 2, 2016 at 7:34 AM Igor Marnat <<a href="mailto:imarnat@mirantis.com" target="_blank">imarnat@mirantis.com</a>> wrote:<br>
><br>
> > Igor,<br>
> > couple of points from my side.<br>
> ><br>
> > CentOS 7.2 will be getting updates for several more months, and we have<br>
> > snapshots and all the mechanics in place to switch to the next version when<br>
> > needed.<br>
> ><br>
> > Speaking of getting this update into 9.0, we actually don't need FFE, we<br>
> > can merge remaining staff today. It has enough reviews, so if you add your<br>
> > +1 today, we don't need FFE.<br>
> ><br>
> > <a href="https://review.openstack.org/#/c/280338/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/280338/</a><br>
> > <a href="https://review.fuel-infra.org/#/c/17400/" rel="noreferrer" target="_blank">https://review.fuel-infra.org/#/c/17400/</a><br>
> ><br>
> ><br>
> ><br>
> > Regards,<br>
> > Igor Marnat<br>
> ><br>
> > On Wed, Mar 2, 2016 at 6:23 PM, Dmitry Teselkin <<a href="mailto:dteselkin@mirantis.com" target="_blank">dteselkin@mirantis.com</a>><br>
> > wrote:<br>
> ><br>
> >> Igor,<br>
> >><br>
> >> Your statement about updates for 7.2 isn't correct - it will receive<br>
> >> updates,  because it's the latest release ATM. There is *no* pinning inside<br>
> >> ISO, and the only place where it was 8.0 were docker containers just<br>
> >> because we had to workaround some issues. But there are no docker<br>
> >> containers in 9.0, so that's not the case.<br>
> >> The proposed solution to switch to CentOS-7.2 in fact is based on<br>
> >> selecting the right snapshot with packages. There is no pinning in ISO (it<br>
> >> was in earlier versions of the spec but was removed).<br>
> >><br>
> >> On Wed, Mar 2, 2016 at 6:11 PM, Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>><br>
> >> wrote:<br>
> >><br>
> >>> Dmitry, Igor,<br>
> >>><br>
> >>> > Very important thing is that CentOS 7.1 which master node is based now<br>
> >>> > don't get updates any longer.<br>
> >>><br>
> >>> If you are using "fixed" release you must be ready that you won't get<br>
> >>> any updates. So with CentOS 7.2 the problem still the same.<br>
> >>><br>
> >>> However, let's wait for Fuel PTL decision. I only shared my POV:<br>
> >>> that's not a critical feature, and taking into account the risks of<br>
> >>> regression - I'd prefer to do not accept it in 9.0.<br>
> >>><br>
> >>> Regards,<br>
> >>> Igor<br>
> >>><br>
> >>> On Wed, Mar 2, 2016 at 4:42 PM, Igor Marnat <<a href="mailto:imarnat@mirantis.com" target="_blank">imarnat@mirantis.com</a>><br>
> >>> wrote:<br>
> >>> > Igor,<br>
> >>> > please note that this is pretty much not like update of master node<br>
> >>> which we<br>
> >>> > had in 8.0. This is minor _update_ of CentOS from 7.1 to 7.2 which team<br>
> >>> > tested for more than 2 months already.<br>
> >>> ><br>
> >>> > We don't expect it to require any additional efforts from core or qa<br>
> >>> team.<br>
> >>> ><br>
> >>> > Very important thing is that CentOS 7.1 which master node is based now<br>
> >>> don't<br>
> >>> > get updates any longer. Updates are only provided for CentOS 7.2.<br>
> >>> ><br>
> >>> > So we'll have to switch CentOS 7.1 to CentOS 7.2 anyways.<br>
> >>> ><br>
> >>> > We can do it now for more or less free, later in release cycle for<br>
> >>> higher<br>
> >>> > risk and QA efforts and after the release for 2x price because of<br>
> >>> additional<br>
> >>> > QA cycle we'll need to pass through.<br>
> >>> ><br>
> >>> ><br>
> >>> ><br>
> >>> > Regards,<br>
> >>> > Igor Marnat<br>
> >>> ><br>
> >>> > On Wed, Mar 2, 2016 at 2:57 PM, Dmitry Teselkin <<br>
> >>> <a href="mailto:dteselkin@mirantis.com" target="_blank">dteselkin@mirantis.com</a>><br>
> >>> > wrote:<br>
> >>> >><br>
> >>> >> Hi Igor,<br>
> >>> >><br>
> >>> >> Postponing this till Fuel 10 means we have to elaborate a plan to do<br>
> >>> such<br>
> >>> >> upgrade for Fuel 9 after the release - the underlying system will not<br>
> >>> get<br>
> >>> >> updated on it's own, and the security issues will not close<br>
> >>> themselves. The<br>
> >>> >> problem here is that such upgrade of deployed master node requires a<br>
> >>> lot of<br>
> >>> >> QA work also.<br>
> >>> >><br>
> >>> >> Since we are not going to update package we build on our own (they<br>
> >>> still<br>
> >>> >> targeted 7.1) switching master node base to CentOS-72 is not that<br>
> >>> dangerous<br>
> >>> >> as it seems.<br>
> >>> >><br>
> >>> >> On Wed, Mar 2, 2016 at 1:54 PM, Igor Kalnitsky <<br>
> >>> <a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>><br>
> >>> >> wrote:<br>
> >>> >>><br>
> >>> >>> Hey Dmitry,<br>
> >>> >>><br>
> >>> >>> No offence, but I rather against that exception. We have too many<br>
> >>> >>> things to do in Mitaka, and moving to CentOS 7.2 means<br>
> >>> >>><br>
> >>> >>> * extra effort from core team<br>
> >>> >>> * extra effort from qa team<br>
> >>> >>><br>
> >>> >>> Moreover, it might block development by introducing unpredictable<br>
> >>> >>> regressions. Remember 8.0? So I think it'd be better to reduce risk<br>
> >>> of<br>
> >>> >>> regressions that affects so many developers by postponing CentOS 7.2<br>
> >>> >>> till Fuel 10.<br>
> >>> >>><br>
> >>> >>> Thanks,<br>
> >>> >>> Igor<br>
> >>> >>><br>
> >>> >>><br>
> >>> >>> On Mon, Feb 29, 2016 at 7:13 PM, Dmitry Teselkin <<br>
> >>> <a href="mailto:dteselkin@mirantis.com" target="_blank">dteselkin@mirantis.com</a>><br>
> >>> >>> wrote:<br>
> >>> >>> > I'd like to ask for a feature freeze exception for switching to<br>
> >>> >>> > CentOS-7.2<br>
> >>> >>> > feature [0].<br>
> >>> >>> ><br>
> >>> >>> > CentOS-7.2 ISO's have been tested periodically since the beginning<br>
> >>> of<br>
> >>> >>> > the<br>
> >>> >>> > year, and all major issues were addressed / fixed at the moment.<br>
> >>> During<br>
> >>> >>> > the<br>
> >>> >>> > last weekend I've made 70 BVT runs to verify that the  solution<br>
> >>> [2] for<br>
> >>> >>> > the<br>
> >>> >>> > last issue - e1000 transmit unit hangs works. And it works, 0<br>
> >>> tests of<br>
> >>> >>> > 35<br>
> >>> >>> > failed [3].<br>
> >>> >>> ><br>
> >>> >>> > Benefits of switching to CentOS-7.2 are quite obvious - we will<br>
> >>> return<br>
> >>> >>> > to<br>
> >>> >>> > latest supported CentOS release, will fix a lot of bugs / security<br>
> >>> >>> > issues<br>
> >>> >>> > [4] and will make further updates easier.<br>
> >>> >>> ><br>
> >>> >>> > Risk of regression still exists, but it's quite low, 35 successful<br>
> >>> BVTs<br>
> >>> >>> > can't be wrong.<br>
> >>> >>> ><br>
> >>> >>> > To finish that feature the following should be done:<br>
> >>> >>> > * review and merge e1000 workaround [2]<br>
> >>> >>> > * review and merge spec [0]<br>
> >>> >>> > * review and merge request that switches build CI to CentOS-7.2 [5]<br>
> >>> >>> ><br>
> >>> >>> > I expect the last day it could be done is March, 4.<br>
> >>> >>> ><br>
> >>> >>> > [0] <a href="https://review.openstack.org/#/c/280338/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/280338/</a><br>
> >>> >>> > [1] <a href="https://bugs.launchpad.net/fuel/+bug/1526544" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1526544</a><br>
> >>> >>> > [2] <a href="https://review.openstack.org/#/c/285306/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/285306/</a><br>
> >>> >>> > [3]<br>
> >>> <a href="https://etherpad.openstack.org/p/r.1c4cfee8185326d6922d6c9321404350" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/r.1c4cfee8185326d6922d6c9321404350</a><br>
> >>> >>> > [4]<br>
> >>> <a href="https://etherpad.openstack.org/p/r.a7fe0b575d891ed81206765fa5be6630" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/r.a7fe0b575d891ed81206765fa5be6630</a><br>
> >>> >>> > [5] <a href="https://review.fuel-infra.org/#/c/17400/" rel="noreferrer" target="_blank">https://review.fuel-infra.org/#/c/17400/</a><br>
> >>> >>> ><br>
> >>> >>> ><br>
> >>> >>> > --<br>
> >>> >>> > Thanks,<br>
> >>> >>> > Dmitry Teselkin<br>
> >>> >>> > Mirantis<br>
> >>> >>> > <a href="http://www.mirantis.com" rel="noreferrer" target="_blank">http://www.mirantis.com</a><br>
> >>> >>> ><br>
> >>> >>> ><br>
> >>> >>> ><br>
> >>> __________________________________________________________________________<br>
> >>> >>> > OpenStack Development Mailing List (not for usage questions)<br>
> >>> >>> > Unsubscribe:<br>
> >>> >>> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >>> >>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>> >>> ><br>
> >>> >>><br>
> >>> >>><br>
> >>> >>><br>
> >>> __________________________________________________________________________<br>
> >>> >>> OpenStack Development Mailing List (not for usage questions)<br>
> >>> >>> Unsubscribe:<br>
> >>> >>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >>> >>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>> >><br>
> >>> >><br>
> >>> >><br>
> >>> >><br>
> >>> >> --<br>
> >>> >> Thanks,<br>
> >>> >> Dmitry Teselkin<br>
> >>> >> Mirantis<br>
> >>> >> <a href="http://www.mirantis.com" rel="noreferrer" target="_blank">http://www.mirantis.com</a><br>
> >>> >><br>
> >>> >><br>
> >>> __________________________________________________________________________<br>
> >>> >> OpenStack Development Mailing List (not for usage questions)<br>
> >>> >> Unsubscribe:<br>
> >>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >>> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>> >><br>
> >>> ><br>
> >>> ><br>
> >>> ><br>
> >>> __________________________________________________________________________<br>
> >>> > OpenStack Development Mailing List (not for usage questions)<br>
> >>> > Unsubscribe:<br>
> >>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>> ><br>
> >>><br>
> >>><br>
> >>> __________________________________________________________________________<br>
> >>> OpenStack Development Mailing List (not for usage questions)<br>
> >>> Unsubscribe:<br>
> >>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>><br>
> >><br>
> >><br>
> >><br>
> >> --<br>
> >> Thanks,<br>
> >> Dmitry Teselkin<br>
> >> Mirantis<br>
> >> <a href="http://www.mirantis.com" rel="noreferrer" target="_blank">http://www.mirantis.com</a><br>
> >><br>
> >> __________________________________________________________________________<br>
> >> OpenStack Development Mailing List (not for usage questions)<br>
> >> Unsubscribe:<br>
> >> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >><br>
> >><br>
> > __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> --<br>
> Mike Scherbakov<br>
> #mihgen<br>
<br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><div dir="ltr">-- <br></div><div dir="ltr">Mike Scherbakov<br>#mihgen</div>