<div dir="ltr">Dmitry, Aleksandra,<div>thank you for help and support! </div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Regards,<div>Igor Marnat</div></div></div></div>
<br><div class="gmail_quote">On Fri, Mar 4, 2016 at 1:20 AM, Aleksandra Fedorova <span dir="ltr"><<a href="mailto:afedorova@mirantis.com" target="_blank">afedorova@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As we agreed, we have switched ISO builds to latest CentOS 7.2 snapshots.<br>
<br>
You can see now that each ISO build (see for ex. [1]) produces several<br>
*_id.txt artifacts.<br>
Note that centos_mirror_id.txt points to CentOS snapshot at<br>
<a href="http://mirror.fuel-infra.org/pkgs/" rel="noreferrer" target="_blank">http://mirror.fuel-infra.org/pkgs/</a><br>
<br>
BVT test is stable, see [2], and nightly system tests results are<br>
basically the same as they were before.<br>
<br>
<br>
[1] <a href="https://ci.fuel-infra.org/job/9.0-community.all/3868/" rel="noreferrer" target="_blank">https://ci.fuel-infra.org/job/9.0-community.all/3868/</a><br>
[2]<br>
<a href="https://ci.fuel-infra.org/view/ISO/job/9.0.fuel_community.ubuntu.bvt_2/" rel="noreferrer" target="_blank">https://ci.fuel-infra.org/view/ISO/job/9.0.fuel_community.ubuntu.bvt_2/</a><br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Mar 3, 2016 at 3:46 AM, Dmitry Borodaenko<br>
<<a href="mailto:dborodaenko@mirantis.com">dborodaenko@mirantis.com</a>> wrote:<br>
> Thanks for the detailed explanation, very helpful!<br>
><br>
> Considering that this change is atomic and easily revertable, lets<br>
> proceed with the change, the sooner we do that the more time we'll have<br>
> to confirm that there is no impact and revert if necessary.<br>
><br>
> --<br>
> Dmitry Borodaenko<br>
><br>
> On Thu, Mar 03, 2016 at 03:40:22AM +0300, Aleksandra Fedorova wrote:<br>
>> Hi,<br>
>><br>
>> let me add some details about the change:<br>
>><br>
>> 1) There are two repositories used to build Fuel ISO: base OS<br>
>> repository [1], and mos repository [2], where we put Fuel dependencies<br>
>> and packages we rebuild due to certain version requirements.<br>
>><br>
>> The CentOS 7.2 feature is related to the upstream repo only. Packages<br>
>> like RabbitMQ, MCollective, Puppet, MySQL and PostgreSQL live in mos<br>
>> repository, which has higher priority then upstream.<br>
>><br>
>> I think we need to setup a separate discussion about our policy<br>
>> regarding these packages, but for now they are fixed and won't be<br>
>> updated by CentOS 7.2 switch.<br>
>><br>
>> 2) This change doesn't affect Fuel codebase.<br>
>><br>
>> The upstream mirror we use for ISO build is controlled by environment<br>
>> variable which is set via Jenkins [3] and can be changed anytime.<br>
>><br>
>> As we have daily snapshots of CentOS repository available at [4], in<br>
>> case of regression in upstream we can pin our builds to stable<br>
>> snapshot and work on the issue without blocking the main development<br>
>> flow.<br>
><br>
> Please make sure that the current snapshot of CentOS 7.1 is not rotated<br>
> away so that we don't loose the point we can revert to.<br>
><br>
>> 3) The "improve snapshotting" work item which is at the moment in<br>
>> progress, will prevent any possibility to "accidentally" migrate to<br>
>> CentOS 7.3, when it becomes available.<br>
>> Thus the only changes which we can fetch from upstream are changes<br>
>> which are published to updates/ component of CentOS 7.2 repo.<br>
>><br>
>><br>
>> As latest BVT on master is green<br>
>>    <a href="https://ci.fuel-infra.org/job/9.0.fuel_community.ubuntu.bvt_2/69/" rel="noreferrer" target="_blank">https://ci.fuel-infra.org/job/9.0.fuel_community.ubuntu.bvt_2/69/</a><br>
>> I think we should proceed with Jenkins reconfiguration [5] and switch<br>
>> to latest snapshots by default.<br>
>><br>
>> [1] currently <a href="http://vault.centos.org/7.1.1503/" rel="noreferrer" target="_blank">http://vault.centos.org/7.1.1503/</a><br>
>> [2] <a href="http://mirror.fuel-infra.org/mos-repos/centos/mos9.0-centos7-fuel/os/x86_64/" rel="noreferrer" target="_blank">http://mirror.fuel-infra.org/mos-repos/centos/mos9.0-centos7-fuel/os/x86_64/</a><br>
>> [3] <a href="https://github.com/fuel-infra/jenkins-jobs/blob/76b5cdf1828b7db1957f7967180d20be099b0c63/common/scripts/all.sh#L84" rel="noreferrer" target="_blank">https://github.com/fuel-infra/jenkins-jobs/blob/76b5cdf1828b7db1957f7967180d20be099b0c63/common/scripts/all.sh#L84</a><br>
>> [4] <a href="http://mirror.fuel-infra.org/pkgs/" rel="noreferrer" target="_blank">http://mirror.fuel-infra.org/pkgs/</a><br>
>> [5] <a href="https://review.fuel-infra.org/#/c/17712/" rel="noreferrer" target="_blank">https://review.fuel-infra.org/#/c/17712/</a><br>
>><br>
>> On Wed, Mar 2, 2016 at 9:22 PM, Mike Scherbakov<br>
>> <<a href="mailto:mscherbakov@mirantis.com">mscherbakov@mirantis.com</a>> wrote:<br>
>> > It is not just about BVT. I'd suggest to monitor situation overall,<br>
>> > including failures of system tests [1]. If we see regressions there, or some<br>
>> > test cases will start flapping (what is even worse), then we'd have to<br>
>> > revert back to CentOS 7.1.<br>
>> ><br>
>> > [1] <a href="https://github.com/openstack/fuel-qa" rel="noreferrer" target="_blank">https://github.com/openstack/fuel-qa</a><br>
>> ><br>
>> > On Wed, Mar 2, 2016 at 10:16 AM Dmitry Borodaenko <<a href="mailto:dborodaenko@mirantis.com">dborodaenko@mirantis.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> 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<br>
>> >> > us<br>
>> >> > instability for some time: from days to a couple of month.<br>
>> >> > Taking this into account and number of other exceptions requested,<br>
>> >> > 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<br>
>> >> > 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">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<br>
>> >> > > have<br>
>> >> > > snapshots and all the mechanics in place to switch to the next version<br>
>> >> > > when<br>
>> >> > > needed.<br>
>> >> > ><br>
>> >> > > Speaking of getting this update into 9.0, we actually don't need FFE,<br>
>> >> > > we<br>
>> >> > > can merge remaining staff today. It has enough reviews, so if you add<br>
>> >> > > 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<br>
>> >> > > <<a href="mailto:dteselkin@mirantis.com">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<br>
>> >> > >> 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<br>
>> >> > >> 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<br>
>> >> > >> <<a href="mailto:ikalnitsky@mirantis.com">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<br>
>> >> > >>> > now<br>
>> >> > >>> > don't get updates any longer.<br>
>> >> > >>><br>
>> >> > >>> If you are using "fixed" release you must be ready that you won't<br>
>> >> > >>> 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">imarnat@mirantis.com</a>><br>
>> >> > >>> wrote:<br>
>> >> > >>> > Igor,<br>
>> >> > >>> > please note that this is pretty much not like update of master<br>
>> >> > >>> > node<br>
>> >> > >>> which we<br>
>> >> > >>> > had in 8.0. This is minor _update_ of CentOS from 7.1 to 7.2 which<br>
>> >> > >>> > team<br>
>> >> > >>> > tested for more than 2 months already.<br>
>> >> > >>> ><br>
>> >> > >>> > We don't expect it to require any additional efforts from core or<br>
>> >> > >>> > qa<br>
>> >> > >>> team.<br>
>> >> > >>> ><br>
>> >> > >>> > Very important thing is that CentOS 7.1 which master node is based<br>
>> >> > >>> > 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">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<br>
>> >> > >>> >> do<br>
>> >> > >>> such<br>
>> >> > >>> >> upgrade for Fuel 9 after the release - the underlying system will<br>
>> >> > >>> >> 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<br>
>> >> > >>> >> requires a<br>
>> >> > >>> lot of<br>
>> >> > >>> >> QA work also.<br>
>> >> > >>> >><br>
>> >> > >>> >> Since we are not going to update package we build on our own<br>
>> >> > >>> >> (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">ikalnitsky@mirantis.com</a>><br>
>> >> > >>> >> wrote:<br>
>> >> > >>> >>><br>
>> >> > >>> >>> Hey Dmitry,<br>
>> >> > >>> >>><br>
>> >> > >>> >>> No offence, but I rather against that exception. We have too<br>
>> >> > >>> >>> 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<br>
>> >> > >>> >>> unpredictable<br>
>> >> > >>> >>> regressions. Remember 8.0? So I think it'd be better to reduce<br>
>> >> > >>> >>> risk<br>
>> >> > >>> of<br>
>> >> > >>> >>> regressions that affects so many developers by postponing CentOS<br>
>> >> > >>> >>> 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">dteselkin@mirantis.com</a>><br>
>> >> > >>> >>> wrote:<br>
>> >> > >>> >>> > I'd like to ask for a feature freeze exception for switching<br>
>> >> > >>> >>> > to<br>
>> >> > >>> >>> > CentOS-7.2<br>
>> >> > >>> >>> > feature [0].<br>
>> >> > >>> >>> ><br>
>> >> > >>> >>> > CentOS-7.2 ISO's have been tested periodically since the<br>
>> >> > >>> >>> > beginning<br>
>> >> > >>> of<br>
>> >> > >>> >>> > the<br>
>> >> > >>> >>> > year, and all major issues were addressed / fixed at the<br>
>> >> > >>> >>> > moment.<br>
>> >> > >>> During<br>
>> >> > >>> >>> > the<br>
>> >> > >>> >>> > last weekend I've made 70 BVT runs to verify that the<br>
>> >> > >>> >>> > 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<br>
>> >> > >>> >>> > will<br>
>> >> > >>> return<br>
>> >> > >>> >>> > to<br>
>> >> > >>> >>> > latest supported CentOS release, will fix a lot of bugs /<br>
>> >> > >>> >>> > security<br>
>> >> > >>> >>> > issues<br>
>> >> > >>> >>> > [4] and will make further updates easier.<br>
>> >> > >>> >>> ><br>
>> >> > >>> >>> > Risk of regression still exists, but it's quite low, 35<br>
>> >> > >>> >>> > 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<br>
>> >> > >>> >>> > 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>
>> >> > >>> __________________________________________________________________________<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>
>> >> > >>> >>> ><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>
>> >> > >>> __________________________________________________________________________<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>
>> >> > >>> >>><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>
>> >> > >>> __________________________________________________________________________<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>
>> >> > >>> __________________________________________________________________________<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>
>> >> > > 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>
>> >> > Mike Scherbakov<br>
>> >> > #mihgen<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>
>> >> 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>
>><br>
>> --<br>
>> Aleksandra Fedorova<br>
>> CI Team Lead<br>
>> bookwar<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>
> 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>
--<br>
Aleksandra Fedorova<br>
CI Team Lead<br>
bookwar<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>
</div></div></blockquote></div><br></div>