<div dir="ltr">Hi team,<div><br></div><div>I think it too late to make such significant changes for MOS 8.0 now, but I'm ok with the idea to remove docker containers in the future releases if our dev team want to do this.</div><div>Any way, before we will do this, we need to plan how we will perform updates between different releases with and without docker containers, how we will manage requirements and etc. In fact we have a lot of questions and haven't answers, let's prepare the spec for this change, review it, discuss it with developers, users and project management team and if we haven't requirements to keep docker containers on master node let's remove them for the future releases (not in MOS 8.0).</div><div><br></div><div>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.</div><div><br></div><div>Thank you!</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 20, 2015 at 4:44 PM, Alexander Kostrikov <span dir="ltr"><<a href="mailto:akostrikov@mirantis.com" target="_blank">akostrikov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello, Igor.<span class=""><div><br></div><div>><span style="font-size:12.8px">But I'd like to hear from QA how do we rely on container-based</span></div><span style="font-size:12.8px">infrastructure? Would it be hard to change our sys-tests in short</span><br style="font-size:12.8px"><span style="font-size:12.8px">time?</span></span><div><span style="font-size:12.8px"><br></span><div>At first glance, system tests are using docker only to fetch logs and run shell commands.</div><div>Also, docker is used to run Rally.</div><div><br></div><div>If there is an action to remove docker containers with carefull attention to bvt testing, it would take couple days to fix system tests.</div><div>But time may be highly affected by code freezes and active features merging.</div></div><div><br></div><div>QA team is going to have Monday (Nov 23) sync-up - and it is possible to get more exact information from all QA-team.</div><div><br></div><div>P.S.</div><div>+1 to remove docker.</div><div>-1 to remove docker without taking into account deadlines/other features.</div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Thu, Nov 19, 2015 at 10:27 PM, Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey guys,<br>
<br>
Despite the fact I like containers (as deployment unit), we 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 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>
<div><div><br>
<br>
On Thu, Nov 19, 2015 at 10:31 AM, Vladimir Kuklin <<a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a>> wrote:<br>
> Folks<br>
><br>
> I guess it should be pretty simple to roll back - install 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" target="_blank">sgolovatiuk@mirantis.com</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> On Thu, Nov 19, 2015 at 5:50 PM, Matthew Mosesohn <<a href="mailto:mmosesohn@mirantis.com" target="_blank">mmosesohn@mirantis.com</a>><br>
>> wrote:<br>
>>><br>
>>> Vladimir,<br>
>>><br>
>>> The old site.pp is long out of date and should just be 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 an update (in<br>
>>> theory, from 8.0 to 9.0, then back to 8.0)? Should we hardcode persistent<br>
>>> data directories (or symlink them?) to<br>
>>> /var/lib/fuel/$fuel_version/$service_name, as we are doing behind the scenes<br>
>>> currently with Docker? If we keep that mechanism in place, all the existing<br>
>>> puppet modules can be used without any modifications. On the same note,<br>
>>> upgrade/rollback is the same as backup and restore, that 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. The similar<br>
>> approach is implemented in CoreOS.<br>
>><br>
>>><br>
>>><br>
>>> On Thu, Nov 19, 2015 at 6:36 PM, Bogdan Dobrelya <<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> On 19.11.2015 15:59, Vladimir Kozhukalov wrote:<br>
>>>> > Dear colleagues,<br>
>>>> ><br>
>>>> > As might remember, we introduced Docker containers on the master node<br>
>>>> > a<br>
>>>> > while ago when we implemented first version of Fuel upgrade feature.<br>
>>>> > The<br>
>>>> > motivation behind was to make it possible to rollback upgrade process<br>
>>>> > if<br>
>>>> > something goes wrong.<br>
>>>> ><br>
>>>> > Now we are at the point where we can not use our tarball based upgrade<br>
>>>> > approach any more and those patches that deprecate upgrade tarball has<br>
>>>> > been already merged. Although it is a matter of a separate discussion,<br>
>>>> > it seems that upgrade process rather should be based on kind of backup<br>
>>>> > and restore procedure. We can backup Fuel data on an external media,<br>
>>>> > then we can install new version of Fuel from scratch and then it is<br>
>>>> > assumed backed up Fuel data can be applied over this new Fuel<br>
>>>> > instance.<br>
>>>><br>
>>>> A side-by-side upgrade, correct? That should work as well.<br>
>>>><br>
>>>> > The procedure itself is under active development, but it is clear that<br>
>>>> > rollback in this case would be nothing more than just restoring from<br>
>>>> > the<br>
>>>> > previously backed up data.<br>
>>>> ><br>
>>>> > As for Docker containers, still there are potential advantages of<br>
>>>> > using<br>
>>>> > them on the Fuel master node, but our current implementation of the<br>
>>>> > feature seems not mature enough to make us benefit 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 example, rpm<br>
>>>> > -qa) for a service like shotgun which is run inside one of<br>
>>>> > containers.<br>
>>>> > * it is specific UX when you first need to run dockerctl shell<br>
>>>> > {container_name} and then you are able to debug something.<br>
>>>> > * when building IBP image we mount directory from the host file<br>
>>>> > system<br>
>>>> > into mcollective container to make image build faster.<br>
>>>> > * there are config files and some other files which should be shared<br>
>>>> > among containers which introduces unnecessary complexity to the<br>
>>>> > whole system.<br>
>>>> > * our current delivery approach assumes we wrap into rpm/deb<br>
>>>> > packages<br>
>>>> > every single piece of the Fuel system. Docker images are not an<br>
>>>> > exception. And as far as they depend on other rpm packages we<br>
>>>> > forced<br>
>>>> > to build docker-images rpm package using kind of specific build<br>
>>>> > flow. Besides this package is quite big (300M).<br>
>>>> > * I'd like it to be possible to install Fuel not from ISO but from<br>
>>>> > RPM<br>
>>>> > repo on any rpm based distribution. But it is double work to<br>
>>>> > support<br>
>>>> > both Docker based and package based approach.<br>
>>>><br>
>>>> There is another point, the containers long build time when installing<br>
>>>> the master node.<br>
>>>><br>
>>>> ><br>
>>>> > Probably some of you can give other examples. Anyway, the idea is to<br>
>>>> > get<br>
>>>> > rid of Docker containers on the master node and switch to plane<br>
>>>> > package<br>
>>>> > based approach that we used before.<br>
>>>> ><br>
>>>> > As far as there is nothing new here, we just need to use our old<br>
>>>> > site.pp<br>
>>>> > (with minimal modifications), it looks like it is possible to<br>
>>>> > implement<br>
>>>> > this during 8.0 release cycle. If there are no principal objections,<br>
>>>> > please give me a chance to do this ASAP (during 8.0), I know it is a<br>
>>>> > huge risk for the release, but still I think I can do this.<br>
>>>> ><br>
>>>> ><br>
>>>> ><br>
>>>> ><br>
>>>> > Vladimir Kozhukalov<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>
>>>> Best regards,<br>
>>>> Bogdan Dobrelya,<br>
>>>> Irc #bogdando<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: <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>
> 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" target="_blank">+7 (495) 640-49-04</a><br>
> <a href="tel:%2B7%20%28926%29%20702-39-68" value="+79267023968" target="_blank">+7 (926) 702-39-68</a><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><br>
> <a href="http://www.mirantis.ru" rel="noreferrer" target="_blank">www.mirantis.ru</a><br>
> <a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</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>
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></div></div><span class="">-- <br><div><div dir="ltr"><p style="margin-bottom:0.0001pt"><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US">Kind Regards,<br></span></p><p style="margin-bottom:0.0001pt"><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US">Alexandr Kostrikov,<br></span></p><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US"><br>Mirantis, Inc.</span><span style="font-family:Arial,sans-serif;color:rgb(31,73,125)" lang="EN-US"></span>
<p style="margin:0cm 0cm 0.0001pt"><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US">35b/3, Vorontsovskaya
St., 109147, Moscow, Russia</span><span style="font-family:Arial,sans-serif;color:rgb(31,73,125)" lang="EN-US"></span></p>
<p style="margin:0cm 0cm 0.0001pt"><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US"><br>
Tel.: <a href="tel:%2B7%20%28495%29%20640-49-04" value="+74956404904" target="_blank">+7 (495) 640-49-04</a><br>
Tel.: <a href="tel:%2B7%20%28906%29%20740-64-79" value="+79067406479" target="_blank">+7 (925) 716-64-52</a></span><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US"></span></p>
<p style="margin:0cm 0cm 0.0001pt"><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US">Skype: akostrikov_mirantis</span></p>
<p style="margin:0cm 0cm 0.0001pt"><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US">E-mail:<span> </span></span><span style="font-size:10pt;font-family:Arial,sans-serif"><a href="mailto:elogutova@mirantis.com" target="_blank"><span style="color:rgb(17,85,204)" lang="EN-US"><span><span><span>akostrikov@mirantis.com</span></span></span></span></a></span><span style="font-family:Arial,sans-serif" lang="EN-US"></span></p>
<p style="margin-bottom:0.0001pt"><u><span style="font-size:10pt;font-family:Arial,sans-serif"><a href="http://www.mirantis.ru/" target="_blank"><span style="color:rgb(17,85,204)" lang="EN-US">www.mirantis.com</span></a></span></u><u><span style="font-size:10pt;font-family:Arial,sans-serif" lang="EN-US"><br>
</span></u><u><span style="font-size:10pt;font-family:Arial,sans-serif"><a href="http://www.mirantis.ru/" target="_blank"><span style="color:rgb(17,85,204)" lang="EN-US">www.mirantis.ru</span></a></span></u><span style="font-family:Arial,sans-serif" lang="EN-US"></span></p></div></div>
</span></div>
<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></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>