<div dir="ltr">Vladimir <div><br></div><div>Although I am a big fan of this idea, I think it is too risky to do this during our latest iteration for 8.0 release. There is a lot of stuff that relies on our containerised approach. For example, it is our Fuel CI master-node tests which will require adjustments. There are pieces of things related to infrastructure for update repositories delivery and so on and so forth. I would assess the risk of this change to break things and block everything as high. So far, I suggest that if we provide a clear deadline when such changes can get into master branch. I think, that we should have all the code including CI jobs in place by Nov 30. Remember - if CI is broken, our feature freeze is also broken. So I would suggest to have a couple of days in advance before feature freeze to revert things.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 19, 2015 at 6:36 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 19.11.2015 15:59, Vladimir Kozhukalov wrote:<br>
> Dear colleagues,<br>
><br>
> As might remember, we introduced Docker containers on the master node a<br>
> while ago when we implemented first version of Fuel upgrade feature. The<br>
> motivation behind was to make it possible to rollback upgrade process 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 instance.<br>
<br>
</span>A side-by-side upgrade, correct? That should work as well.<br>
<span class=""><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 the<br>
> previously backed up data.<br>
><br>
> As for Docker containers, still there are potential advantages of 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>
</span>>   * it is tricky to get logs and other information (for example, rpm<br>
<span class="">>     -qa) for a service like shotgun which is run inside one of containers.<br>
</span>>   * it is specific UX when you first need to run dockerctl shell<br>
<span class="">>     {container_name} and then you are able to debug something.<br>
</span>>   * when building IBP image we mount directory from the host file system<br>
<span class="">>     into mcollective container to make image build faster.<br>
</span>>   * there are config files and some other files which should be shared<br>
<span class="">>     among containers which introduces unnecessary complexity to the<br>
>     whole system.<br>
</span>>   * our current delivery approach assumes we wrap into rpm/deb packages<br>
<span class="">>     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 forced<br>
>     to build docker-images rpm package using kind of specific build<br>
>     flow. Besides this package is quite big (300M).<br>
</span>>   * I'd like it to be possible to install Fuel not from ISO but from RPM<br>
<span class="">>     repo on any rpm based distribution. But it is double work to support<br>
>     both Docker based and package based approach.<br>
<br>
</span>There is another point, the containers long build time when installing<br>
the master node.<br>
<span class=""><br>
><br>
> Probably some of you can give other examples. Anyway, the idea is to get<br>
> rid of Docker containers on the master node and switch to plane 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 site.pp<br>
> (with minimal modifications), it looks like it is possible to 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>
</span>> __________________________________________________________________________<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>
<span class="HOEnZb"><font color="#888888"><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>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">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.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div>