<div dir="ltr">Hi Igor and Alexander,<div><br><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" class="gmail_quote">><span style="font-size:12.8px">But I'd like to hear from QA how do we rely on container-based<br></span><span style="color:rgb(80,0,80);font-size:12.8px">infrastructure? Would it be hard to change our sys-tests in short<br></span><span style="color:rgb(80,0,80);font-size:12.8px">time?</span></blockquote></div><div>QA team hadn't significant dependencies from docker images in our tests [0], <span style="font-size:12.8px">I think we can change all docker-based code from our tests / scripts in 2-3 days, but it is hard to predict when ISO without docker images will pass all SWARM / Tempest tests.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">And one more time:</span></div><div><span class="im"><blockquote class="gmail_quote" style="font-size:12.8px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">Of course, we can fix BVT / SWARM tests and don't use docker images in our test suite (it shouldn't be really hard) but we didn't plan these changes and in fact these changes can affect our estimates for many tasks.</span></blockquote><div style="font-size:12.8px"><br></div><span style="background-color:rgb(255,255,255)"><font color="#000000">Do we really want to remove docker containers from master node? How long it will take to provide the experimental MOS 8.0 build without docker containers?<br>Are we ready to change the date of MOS 8.0 release and make this change?</font></span></span></div><div><span class="im"><span style="background-color:rgb(255,255,255)"><font color="#000000"><br></font></span></span></div><div><span class="im"><span style="background-color:rgb(255,255,255)"><font color="#000000">[0] </font></span></span><font color="#000000"><a href="https://github.com/openstack/fuel-qa/search?p=2&q=docker&utf8=%E2%9C%93">https://github.com/openstack/fuel-qa/search?p=2&q=docker&utf8=%E2%9C%93</a></font></div><div><span class="im"><span style="background-color:rgb(255,255,255)"><font color="#000000"><br></font></span></span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 20, 2015 at 7:57 PM, Bogdan Dobrelya <span dir="ltr"><<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 20.11.2015 17:31, Vladimir Kozhukalov wrote:<br>
> Bogdan,<br>
><br>
>>> So, we could only deprecate the docker feature for the 8.0.<br>
><br>
> What do you mean exactly when saying 'deprecate docker feature'? I can<br>
> not even imagine how we can live with and without docker containers at<br>
> the same time. Deprecation is usually related to features which directly<br>
> impact UX (maybe I am wrong).<br>
<br>
</span>I may be understood this [0] wrong, and the docker containers are not<br>
user-visible, but that depends on the which type of users do we mean :-)<br>
Sorry, for being not clear.<br>
<br>
[0]<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html</a><br>
<span class=""><br>
><br>
> Guys,<br>
><br>
> When you estimate risks of the docker removal, please take into account<br>
> not only release deadlines but also the overall product quality. The<br>
> thing is that continuing using containers makes it much more complicated<br>
> (and thus less stable) to implement new upgrade flow (upgrade tarball<br>
> can not be used any more, we need to re-install the host system).<br>
> Switching from Centos 6 to Centos 7 is also much more complicated with<br>
> docker. Every single piece of Fuel system is going to become simpler and<br>
> easier to support.<br>
><br>
> Of course, I am not suggesting to jump overboard into cold water without<br>
> a life jacket. Transition plan, checklist, green tests, even spec etc.<br>
> are assumed without saying (after all, I was not born yesterday). Of<br>
> course, we won't merge changes until everything is green. What is the<br>
> problem to try to do this and postpone if not ready in time? And please<br>
> do not confuse these two cases: switching from plain deployment to<br>
> containers is complicated, but switching from docker to plain is much<br>
> simpler.<br>
><br>
><br>
><br>
><br>
> Vladimir Kozhukalov<br>
><br>
> On Fri, Nov 20, 2015 at 6:47 PM, Bogdan Dobrelya <<a href="mailto:bdobrelia@mirantis.com">bdobrelia@mirantis.com</a><br>
</span><span class="">> <mailto:<a href="mailto:bdobrelia@mirantis.com">bdobrelia@mirantis.com</a>>> wrote:<br>
><br>
> On 20.11.2015 15:10, Timur Nurlygayanov wrote:<br>
> > Hi team,<br>
> ><br>
> > I think it too late to make such significant changes for MOS 8.0 now,<br>
> > but I'm ok with the idea to remove docker containers in the future<br>
> > releases if our dev team want to do this.<br>
> > Any way, before we will do this, we need to plan how we will perform<br>
> > updates between different releases with and without docker containers,<br>
> > how we will manage requirements and etc. In fact we have a lot of<br>
> > questions and haven't answers, let's prepare the spec for this change,<br>
> > review it, discuss it with developers, users and project management team<br>
> > and if we haven't requirements to keep docker containers on master node<br>
> > let's remove them for the future releases (not in MOS 8.0).<br>
> ><br>
> > Of course, we can fix BVT / SWARM tests and don't use docker images in<br>
> > our test suite (it shouldn't be really hard) but we didn't plan these<br>
> > changes and in fact these changes can affect our estimates for many tasks.<br>
><br>
> I can only add that features just cannot be removed without a<br>
> deprecation period of 1-2 releases.<br>
> So, we could only deprecate the docker feature for the 8.0.<br>
><br>
> ><br>
> > Thank you!<br>
> ><br>
> ><br>
> > On Fri, Nov 20, 2015 at 4:44 PM, Alexander Kostrikov<br>
> > <<a href="mailto:akostrikov@mirantis.com">akostrikov@mirantis.com</a> <mailto:<a href="mailto:akostrikov@mirantis.com">akostrikov@mirantis.com</a>><br>
</span>> <mailto:<a href="mailto:akostrikov@mirantis.com">akostrikov@mirantis.com</a> <mailto:<a href="mailto:akostrikov@mirantis.com">akostrikov@mirantis.com</a>>>><br>
<span class="">> wrote:<br>
> ><br>
> > Hello, Igor.<br>
> ><br>
> > >But I'd like to hear from QA how do we rely on container-based<br>
> > infrastructure? Would it be hard to change our sys-tests in short<br>
> > time?<br>
> ><br>
> > At first glance, system tests are using docker only to fetch logs<br>
> > and run shell commands.<br>
> > Also, docker is used to run Rally.<br>
> ><br>
> > If there is an action to remove docker containers with carefull<br>
> > attention to bvt testing, it would take couple days to fix system tests.<br>
> > But time may be highly affected by code freezes and active features<br>
> > merging.<br>
> ><br>
> > QA team is going to have Monday (Nov 23) sync-up - and it is<br>
> > possible to get more exact information from all QA-team.<br>
> ><br>
> > P.S.<br>
> > +1 to remove docker.<br>
> > -1 to remove docker without taking into account deadlines/other<br>
> > features.<br>
> ><br>
> > On Thu, Nov 19, 2015 at 10:27 PM, Igor Kalnitsky<br>
> > <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a> <mailto:<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>><br>
</span>> <mailto:<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a> <mailto:<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>>>><br>
<span class="">> wrote:<br>
> ><br>
> > Hey guys,<br>
> ><br>
> > Despite the fact I like containers (as deployment unit), we<br>
> > don't use<br>
> > them so. That means I +1 idea to drop containers, just because I<br>
> > believe that would<br>
> ><br>
> > * simplify a lot of things<br>
> > * helps get rid of huge amount of hacks<br>
> > * increase master node deployment<br>
> > * release us from annoying support of upgrades / rollbacks that<br>
> > proved<br>
> > to be non-working well<br>
> ><br>
> > But I'd like to hear from QA how do we rely on container-based<br>
> > infrastructure? Would it be hard to change our sys-tests in short<br>
> > time?<br>
> ><br>
> > Thanks,<br>
> > Igor<br>
> ><br>
> ><br>
> > On Thu, Nov 19, 2015 at 10:31 AM, Vladimir Kuklin<br>
> > <<a href="mailto:vkuklin@mirantis.com">vkuklin@mirantis.com</a> <mailto:<a href="mailto:vkuklin@mirantis.com">vkuklin@mirantis.com</a>><br>
</span><span class="">> <mailto:<a href="mailto:vkuklin@mirantis.com">vkuklin@mirantis.com</a> <mailto:<a href="mailto:vkuklin@mirantis.com">vkuklin@mirantis.com</a>>>> wrote:<br>
> > > Folks<br>
> > ><br>
> > > I guess it should be pretty simple to roll back - install<br>
> > older version and<br>
> > > restore the backup with preservation of /var/log directory.<br>
> > ><br>
> > > On Thu, Nov 19, 2015 at 7:38 PM, Sergii Golovatiuk<br>
> > > <<a href="mailto:sgolovatiuk@mirantis.com">sgolovatiuk@mirantis.com</a><br>
</span>> <mailto:<a href="mailto:sgolovatiuk@mirantis.com">sgolovatiuk@mirantis.com</a>> <mailto:<a href="mailto:sgolovatiuk@mirantis.com">sgolovatiuk@mirantis.com</a><br>
<span class="">> <mailto:<a href="mailto:sgolovatiuk@mirantis.com">sgolovatiuk@mirantis.com</a>>>><br>
> > wrote:<br>
> > >><br>
> > >> Hi,<br>
> > >><br>
> > >> On Thu, Nov 19, 2015 at 5:50 PM, Matthew Mosesohn<br>
> > <<a href="mailto:mmosesohn@mirantis.com">mmosesohn@mirantis.com</a> <mailto:<a href="mailto:mmosesohn@mirantis.com">mmosesohn@mirantis.com</a>><br>
</span>> <mailto:<a href="mailto:mmosesohn@mirantis.com">mmosesohn@mirantis.com</a> <mailto:<a href="mailto:mmosesohn@mirantis.com">mmosesohn@mirantis.com</a>>>><br>
<div><div class="h5">> > >> wrote:<br>
> > >>><br>
> > >>> Vladimir,<br>
> > >>><br>
> > >>> The old site.pp is long out of date and should just be<br>
> > recreated from the<br>
> > >>> content of all the other $service-only.pp files.<br>
> > >>><br>
> > >>> My main question is how do we propose to do a rollback from<br>
> > an update (in<br>
> > >>> theory, from 8.0 to 9.0, then back to 8.0)? Should we<br>
> > hardcode persistent<br>
> > >>> data directories (or symlink them?) to<br>
> > >>> /var/lib/fuel/$fuel_version/$service_name, as we are doing<br>
> > behind the scenes<br>
> > >>> currently with Docker? If we keep that mechanism in place,<br>
> > all the existing<br>
> > >>> puppet modules can be used without any modifications. On the<br>
> > same note,<br>
> > >>> upgrade/rollback is the same as backup and restore, that<br>
> > means our restore<br>
> > >>> should follow a similar approach.<br>
> > >>> -Matthew<br>
> > >><br>
> > >><br>
> > >> There only one idea I have is to do dual partitioning system.<br>
> > The similar<br>
> > >> approach is implemented in CoreOS.<br>
> > >><br>
> > >>><br>
> > >>><br>
> > >>> On Thu, Nov 19, 2015 at 6:36 PM, Bogdan Dobrelya<br>
> > <<a href="mailto:bdobrelia@mirantis.com">bdobrelia@mirantis.com</a> <mailto:<a href="mailto:bdobrelia@mirantis.com">bdobrelia@mirantis.com</a>><br>
</div></div>> <mailto:<a href="mailto:bdobrelia@mirantis.com">bdobrelia@mirantis.com</a> <mailto:<a href="mailto:bdobrelia@mirantis.com">bdobrelia@mirantis.com</a>>>><br>
<div><div class="h5">> > >>> wrote:<br>
> > >>>><br>
> > >>>> On 19.11.2015 15:59, Vladimir Kozhukalov wrote:<br>
> > >>>> > Dear colleagues,<br>
> > >>>> ><br>
> > >>>> > As might remember, we introduced Docker containers<br>
> on the<br>
> > master node<br>
> > >>>> > a<br>
> > >>>> > while ago when we implemented first version of Fuel<br>
> > upgrade feature.<br>
> > >>>> > The<br>
> > >>>> > motivation behind was to make it possible to rollback<br>
> > upgrade process<br>
> > >>>> > if<br>
> > >>>> > something goes wrong.<br>
> > >>>> ><br>
> > >>>> > Now we are at the point where we can not use our<br>
> tarball<br>
> > based upgrade<br>
> > >>>> > approach any more and those patches that deprecate<br>
> > upgrade tarball has<br>
> > >>>> > been already merged. Although it is a matter of a<br>
> > separate discussion,<br>
> > >>>> > it seems that upgrade process rather should be based on<br>
> > kind of backup<br>
> > >>>> > and restore procedure. We can backup Fuel data on an<br>
> > external media,<br>
> > >>>> > then we can install new version of Fuel from<br>
> scratch and<br>
> > then it is<br>
> > >>>> > assumed backed up Fuel data can be applied over<br>
> this new Fuel<br>
> > >>>> > instance.<br>
> > >>>><br>
> > >>>> A side-by-side upgrade, correct? That should work as<br>
> well.<br>
> > >>>><br>
> > >>>> > The procedure itself is under active development,<br>
> but it<br>
> > is clear that<br>
> > >>>> > rollback in this case would be nothing more than just<br>
> > restoring from<br>
> > >>>> > the<br>
> > >>>> > previously backed up data.<br>
> > >>>> ><br>
> > >>>> > As for Docker containers, still there are potential<br>
> > advantages of<br>
> > >>>> > using<br>
> > >>>> > them on the Fuel master node, but our current<br>
> > implementation of the<br>
> > >>>> > feature seems not mature enough to make us benefit<br>
> from the<br>
> > >>>> > containerization.<br>
> > >>>> ><br>
> > >>>> > At the same time there are some disadvantages like<br>
> > >>>> ><br>
> > >>>> > * it is tricky to get logs and other information (for<br>
> > example, rpm<br>
> > >>>> > -qa) for a service like shotgun which is run inside<br>
> > one of<br>
> > >>>> > containers.<br>
> > >>>> > * it is specific UX when you first need to run<br>
> > dockerctl shell<br>
> > >>>> > {container_name} and then you are able to debug<br>
> > something.<br>
> > >>>> > * when building IBP image we mount directory from the<br>
> > host file<br>
> > >>>> > system<br>
> > >>>> > into mcollective container to make image build<br>
> faster.<br>
> > >>>> > * there are config files and some other files which<br>
> > should be shared<br>
> > >>>> > among containers which introduces unnecessary<br>
> > complexity to the<br>
> > >>>> > whole system.<br>
> > >>>> > * our current delivery approach assumes we wrap into<br>
> > rpm/deb<br>
> > >>>> > packages<br>
> > >>>> > every single piece of the Fuel system. Docker<br>
> images<br>
> > are not an<br>
> > >>>> > exception. And as far as they depend on other rpm<br>
> > packages we<br>
> > >>>> > forced<br>
> > >>>> > to build docker-images rpm package using kind of<br>
> > specific build<br>
> > >>>> > flow. Besides this package is quite big (300M).<br>
> > >>>> > * I'd like it to be possible to install Fuel not from<br>
> > ISO but from<br>
> > >>>> > RPM<br>
> > >>>> > repo on any rpm based distribution. But it is<br>
> double<br>
> > work to<br>
> > >>>> > support<br>
> > >>>> > both Docker based and package based approach.<br>
> > >>>><br>
> > >>>> There is another point, the containers long build<br>
> time when<br>
> > installing<br>
> > >>>> the master node.<br>
> > >>>><br>
> > >>>> ><br>
> > >>>> > Probably some of you can give other examples.<br>
> Anyway, the<br>
> > idea is to<br>
> > >>>> > get<br>
> > >>>> > rid of Docker containers on the master node and<br>
> switch to<br>
> > plane<br>
> > >>>> > package<br>
> > >>>> > based approach that we used before.<br>
> > >>>> ><br>
> > >>>> > As far as there is nothing new here, we just need<br>
> to use<br>
> > our old<br>
> > >>>> > site.pp<br>
> > >>>> > (with minimal modifications), it looks like it is<br>
> possible to<br>
> > >>>> > implement<br>
> > >>>> > this during 8.0 release cycle. If there are no<br>
> principal<br>
> > objections,<br>
> > >>>> > please give me a chance to do this ASAP (during 8.0), I<br>
> > know it is a<br>
> > >>>> > huge risk for the release, but still I think I can<br>
> do this.<br>
> > >>>> ><br>
> > >>>> ><br>
> > >>>> ><br>
> > >>>> ><br>
> > >>>> > Vladimir Kozhukalov<br>
> > >>>> ><br>
> > >>>> ><br>
> > >>>> ><br>
> > >>>> ><br>
> ><br>
> __________________________________________________________________________<br>
> > >>>> > OpenStack Development Mailing List (not for usage<br>
> questions)<br>
> > >>>> > Unsubscribe:<br>
> > >>>> ><br>
> ><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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
> ><br>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://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>
> > >>>> Best regards,<br>
> > >>>> Bogdan Dobrelya,<br>
> > >>>> Irc #bogdando<br>
> > >>>><br>
> > >>>><br>
> > >>>><br>
> > __________________________________________________________________________<br>
> > >>>> OpenStack Development Mailing List (not for usage questions)<br>
> > >>>> Unsubscribe:<br>
> > >>>><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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
> ><br>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://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>
> > >>><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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
> ><br>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://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>
> > >> 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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
> ><br>
</div></div><span class="">> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://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>
> > > Yours Faithfully,<br>
> > > Vladimir Kuklin,<br>
> > > Fuel Library Tech Lead,<br>
> > > Mirantis, Inc.<br>
> > > <a href="tel:%2B7%20%28495%29%20640-49-04" value="+74956404904">+7 (495) 640-49-04</a> <tel:%2B7%20%28495%29%20640-49-04><br>
> > > <a href="tel:%2B7%20%28926%29%20702-39-68" value="+79267023968">+7 (926) 702-39-68</a> <tel:%2B7%20%28926%29%20702-39-68><br>
> > > Skype kuklinvv<br>
> > > 35bk3, Vorontsovskaya Str.<br>
> > > Moscow, Russia,<br>
> > > <a href="http://www.mirantis.com" rel="noreferrer" target="_blank">www.mirantis.com</a> <<a href="http://www.mirantis.com" rel="noreferrer" target="_blank">http://www.mirantis.com</a>><br>
> <<a href="http://www.mirantis.com" rel="noreferrer" target="_blank">http://www.mirantis.com</a>><br>
> > > <a href="http://www.mirantis.ru" rel="noreferrer" target="_blank">www.mirantis.ru</a> <<a href="http://www.mirantis.ru" rel="noreferrer" target="_blank">http://www.mirantis.ru</a>><br>
> <<a href="http://www.mirantis.ru" rel="noreferrer" target="_blank">http://www.mirantis.ru</a>><br>
> > > <a href="mailto:vkuklin@mirantis.com">vkuklin@mirantis.com</a> <mailto:<a href="mailto:vkuklin@mirantis.com">vkuklin@mirantis.com</a>><br>
</span>> <mailto:<a href="mailto:vkuklin@mirantis.com">vkuklin@mirantis.com</a> <mailto:<a href="mailto:vkuklin@mirantis.com">vkuklin@mirantis.com</a>>><br>
<span class="">> > ><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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
> ><br>
</span><span class="">> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://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:<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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
> ><br>
</span><span class="">> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://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>
> > Kind Regards,<br>
> ><br>
> > Alexandr Kostrikov,<br>
> ><br>
> ><br>
> > Mirantis, Inc.<br>
> ><br>
> > 35b/3, Vorontsovskaya St., 109147, Moscow, Russia<br>
> ><br>
> ><br>
> > Tel.: <a href="tel:%2B7%20%28495%29%20640-49-04" value="+74956404904">+7 (495) 640-49-04</a> <tel:%2B7%20%28495%29%20640-49-04><br>
> > Tel.: <a href="tel:%2B7%20%28925%29%20716-64-52" value="+79257166452">+7 (925) 716-64-52</a> <tel:%2B7%20%28906%29%20740-64-79><br>
> ><br>
> > Skype: akostrikov_mirantis<br>
> ><br>
> > <a href="mailto:E-mail%3Aakostrikov@mirantis.com">E-mail:akostrikov@mirantis.com</a><br>
</span>> <mailto:<a href="mailto:E-mail%253Aakostrikov@mirantis.com">E-mail%3Aakostrikov@mirantis.com</a>><br>
> <mailto:<a href="mailto:elogutova@mirantis.com">elogutova@mirantis.com</a> <mailto:<a href="mailto:elogutova@mirantis.com">elogutova@mirantis.com</a>>><br>
> ><br>
> > _<a href="http://www.mirantis.com" rel="noreferrer" target="_blank">www.mirantis.com</a> <<a href="http://www.mirantis.com" rel="noreferrer" target="_blank">http://www.mirantis.com</a>><br>
<span class="im HOEnZb">> <<a href="http://www.mirantis.ru/" rel="noreferrer" target="_blank">http://www.mirantis.ru/</a>>__<br>
> > __<a href="http://www.mirantis.ru" rel="noreferrer" target="_blank">www.mirantis.ru</a> <<a href="http://www.mirantis.ru" rel="noreferrer" target="_blank">http://www.mirantis.ru</a>><br>
> <<a href="http://www.mirantis.ru/" rel="noreferrer" target="_blank">http://www.mirantis.ru/</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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
> ><br>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://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>
> > Timur,<br>
> > Senior QA Engineer<br>
> > OpenStack Projects<br>
> > Mirantis Inc<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>
</span><span class="im HOEnZb">> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://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>
> Best regards,<br>
> Bogdan Dobrelya,<br>
> Irc #bogdando<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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://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: <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>
</span><div class="HOEnZb"><div class="h5">> <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>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<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><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font color="#888888"><font color="#888888"><br></font></font><div style="font-family:arial;font-size:small">Timur,</div><div style="font-family:arial;font-size:small">Senior QA Engineer</div><div style="font-family:arial;font-size:small">OpenStack Projects</div><div style="font-family:arial;font-size:small">Mirantis Inc</div></div></div></div></div></div></div>
</div>