<div dir="ltr">+1 to remove docker in new CentOS 7.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 20, 2015 at 7:31 PM, Vladimir Kozhukalov <span dir="ltr"><<a href="mailto:vkozhukalov@mirantis.com" target="_blank">vkozhukalov@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">Bogdan,<span class=""><div><br></div><div>>> So, we could only deprecate the docker feature for the 8.0.<br></div><div><br></div></span><div>What do you mean exactly when saying 'deprecate docker feature'? I can not even imagine how we can live with and without docker containers at the same time. Deprecation is usually related to features which directly impact UX (maybe I am wrong). </div><div><br></div><div>Guys, </div><div><br></div><div>When you estimate risks of the docker removal, please take into account not only release deadlines but also the overall product quality. The thing is that continuing using containers makes it much more complicated (and thus less stable) to implement new upgrade flow (upgrade tarball can not be used any more, we need to re-install the host system). Switching from Centos 6 to Centos 7 is also much more complicated with docker. Every single piece of Fuel system is going to become simpler and easier to support.</div><div><br></div><div>Of course, I am not suggesting to jump overboard into cold water without a life jacket. Transition plan, checklist, green tests, even spec etc. are assumed without saying (after all, I was not born yesterday). Of course, we won't merge changes until everything is green. What is the problem to try to do this and postpone if not ready in time? And please do not confuse these two cases: switching from plain deployment to containers is complicated, but switching from docker to plain is much simpler. </div><span class="HOEnZb"><font color="#888888"><div><br></div><div><br></div><div><br></div></font></span></div><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div><div>Vladimir Kozhukalov</div></div></div></font></span><div><div class="h5">
<br><div class="gmail_quote">On Fri, Nov 20, 2015 at 6:47 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>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>
</span>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>
<span><br>
><br>
> Thank you!<br>
><br>
><br>
> On Fri, Nov 20, 2015 at 4:44 PM, Alexander Kostrikov<br>
</span><span>> <<a href="mailto:akostrikov@mirantis.com" target="_blank">akostrikov@mirantis.com</a> <mailto:<a href="mailto:akostrikov@mirantis.com" target="_blank">akostrikov@mirantis.com</a>>> 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>
</span><span>> <<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a> <mailto:<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>>> 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>
</span><span>> <<a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a> <mailto:<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<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>
</span>> > <<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">sgolovatiuk@mirantis.com</a> <mailto:<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">sgolovatiuk@mirantis.com</a>>><br>
<span>> wrote:<br>
> >><br>
> >> Hi,<br>
> >><br>
> >> On Thu, Nov 19, 2015 at 5:50 PM, Matthew Mosesohn<br>
</span>> <<a href="mailto:mmosesohn@mirantis.com" target="_blank">mmosesohn@mirantis.com</a> <mailto:<a href="mailto:mmosesohn@mirantis.com" target="_blank">mmosesohn@mirantis.com</a>>><br>
<span>> >> 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>
</span>> <<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a> <mailto:<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a>>><br>
<div><div>> >>> 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<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 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 scratch and<br>
> 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<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 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 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 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 double<br>
> work to<br>
> >>>> > support<br>
> >>>> > both Docker based and package based approach.<br>
> >>>><br>
> >>>> There is another point, the containers long build time when<br>
> installing<br>
> >>>> the master node.<br>
> >>>><br>
> >>>> ><br>
> >>>> > Probably some of you can give other examples. Anyway, the<br>
> idea is to<br>
> >>>> > get<br>
> >>>> > rid of Docker containers on the master node and 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 to use<br>
> 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<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 do this.<br>
> >>>> ><br>
> >>>> ><br>
> >>>> ><br>
> >>>> ><br>
> >>>> > Vladimir Kozhukalov<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>
</div></div>> <<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>
<span>> >>>> ><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>
</span>> <<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>
<span>> >>>><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>
</span>> <<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>
<span>> >>><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>
</span>> <<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>
<span>> >> <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>
</span>> > +7 (495) 640-49-04 <tel:%2B7%20%28495%29%20640-49-04><br>
> > +7 (926) 702-39-68 <tel:%2B7%20%28926%29%20702-39-68><br>
<span>> > Skype kuklinvv<br>
> > 35bk3, Vorontsovskaya Str.<br>
> > Moscow, Russia,<br>
</span>> > <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.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="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a> <mailto:<a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a>><br>
<span>> ><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>> <<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>
<span>> > <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>
</span>> <<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>
<span>> <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>
</span>> Tel.: +7 (495) 640-49-04 <tel:%2B7%20%28495%29%20640-49-04><br>
> Tel.: +7 (925) 716-64-52 <tel:%2B7%20%28906%29%20740-64-79><br>
><br>
> Skype: akostrikov_mirantis<br>
><br>
> <a href="mailto:E-mail%3Aakostrikov@mirantis.com" target="_blank">E-mail:akostrikov@mirantis.com</a> <mailto:<a href="mailto:elogutova@mirantis.com" target="_blank">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.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>
<span>><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>> <<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>
<span>> <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>
</span><div><div>> __________________________________________________________________________<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>
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></div></div></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></div>