<div dir="ltr">Hello, Igor.<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><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"><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 class="HOEnZb"><div class="h5"><br>
<br>
On Thu, Nov 19, 2015 at 10:31 AM, Vladimir Kuklin <<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 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>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> On Thu, Nov 19, 2015 at 5:50 PM, Matthew Mosesohn <<a href="mailto:mmosesohn@mirantis.com">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">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>
> +7 (495) 640-49-04<br>
> +7 (926) 702-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><br>
> <a href="http://www.mirantis.ru" rel="noreferrer" target="_blank">www.mirantis.ru</a><br>
> <a href="mailto:vkuklin@mirantis.com">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>-- <br><div class="gmail_signature"><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>
</div>