On 20.11.2015 15:10, Timur Nurlygayanov wrote: > Hi team, > > 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. > 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). > > 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.
I can only add that features just cannot be removed without a deprecation period of 1-2 releases. So, we could only deprecate the docker feature for the 8.0. > > Thank you! > > > On Fri, Nov 20, 2015 at 4:44 PM, Alexander Kostrikov > <akostri...@mirantis.com <mailto:akostri...@mirantis.com>> wrote: > > Hello, Igor. > > >But I'd like to hear from QA how do we rely on container-based > infrastructure? Would it be hard to change our sys-tests in short > time? > > At first glance, system tests are using docker only to fetch logs > and run shell commands. > Also, docker is used to run Rally. > > If there is an action to remove docker containers with carefull > attention to bvt testing, it would take couple days to fix system tests. > But time may be highly affected by code freezes and active features > merging. > > QA team is going to have Monday (Nov 23) sync-up - and it is > possible to get more exact information from all QA-team. > > P.S. > +1 to remove docker. > -1 to remove docker without taking into account deadlines/other > features. > > On Thu, Nov 19, 2015 at 10:27 PM, Igor Kalnitsky > <ikalnit...@mirantis.com <mailto:ikalnit...@mirantis.com>> wrote: > > Hey guys, > > Despite the fact I like containers (as deployment unit), we > don't use > them so. That means I +1 idea to drop containers, just because I > believe that would > > * simplify a lot of things > * helps get rid of huge amount of hacks > * increase master node deployment > * release us from annoying support of upgrades / rollbacks that > proved > to be non-working well > > But I'd like to hear from QA how do we rely on container-based > infrastructure? Would it be hard to change our sys-tests in short > time? > > Thanks, > Igor > > > On Thu, Nov 19, 2015 at 10:31 AM, Vladimir Kuklin > <vkuk...@mirantis.com <mailto:vkuk...@mirantis.com>> wrote: > > Folks > > > > I guess it should be pretty simple to roll back - install > older version and > > restore the backup with preservation of /var/log directory. > > > > On Thu, Nov 19, 2015 at 7:38 PM, Sergii Golovatiuk > > <sgolovat...@mirantis.com <mailto:sgolovat...@mirantis.com>> > wrote: > >> > >> Hi, > >> > >> On Thu, Nov 19, 2015 at 5:50 PM, Matthew Mosesohn > <mmoses...@mirantis.com <mailto:mmoses...@mirantis.com>> > >> wrote: > >>> > >>> Vladimir, > >>> > >>> The old site.pp is long out of date and should just be > recreated from the > >>> content of all the other $service-only.pp files. > >>> > >>> My main question is how do we propose to do a rollback from > an update (in > >>> theory, from 8.0 to 9.0, then back to 8.0)? Should we > hardcode persistent > >>> data directories (or symlink them?) to > >>> /var/lib/fuel/$fuel_version/$service_name, as we are doing > behind the scenes > >>> currently with Docker? If we keep that mechanism in place, > all the existing > >>> puppet modules can be used without any modifications. On the > same note, > >>> upgrade/rollback is the same as backup and restore, that > means our restore > >>> should follow a similar approach. > >>> -Matthew > >> > >> > >> There only one idea I have is to do dual partitioning system. > The similar > >> approach is implemented in CoreOS. > >> > >>> > >>> > >>> On Thu, Nov 19, 2015 at 6:36 PM, Bogdan Dobrelya > <bdobre...@mirantis.com <mailto:bdobre...@mirantis.com>> > >>> wrote: > >>>> > >>>> On 19.11.2015 15:59, Vladimir Kozhukalov wrote: > >>>> > Dear colleagues, > >>>> > > >>>> > As might remember, we introduced Docker containers on the > master node > >>>> > a > >>>> > while ago when we implemented first version of Fuel > upgrade feature. > >>>> > The > >>>> > motivation behind was to make it possible to rollback > upgrade process > >>>> > if > >>>> > something goes wrong. > >>>> > > >>>> > Now we are at the point where we can not use our tarball > based upgrade > >>>> > approach any more and those patches that deprecate > upgrade tarball has > >>>> > been already merged. Although it is a matter of a > separate discussion, > >>>> > it seems that upgrade process rather should be based on > kind of backup > >>>> > and restore procedure. We can backup Fuel data on an > external media, > >>>> > then we can install new version of Fuel from scratch and > then it is > >>>> > assumed backed up Fuel data can be applied over this new Fuel > >>>> > instance. > >>>> > >>>> A side-by-side upgrade, correct? That should work as well. > >>>> > >>>> > The procedure itself is under active development, but it > is clear that > >>>> > rollback in this case would be nothing more than just > restoring from > >>>> > the > >>>> > previously backed up data. > >>>> > > >>>> > As for Docker containers, still there are potential > advantages of > >>>> > using > >>>> > them on the Fuel master node, but our current > implementation of the > >>>> > feature seems not mature enough to make us benefit from the > >>>> > containerization. > >>>> > > >>>> > At the same time there are some disadvantages like > >>>> > > >>>> > * it is tricky to get logs and other information (for > example, rpm > >>>> > -qa) for a service like shotgun which is run inside > one of > >>>> > containers. > >>>> > * it is specific UX when you first need to run > dockerctl shell > >>>> > {container_name} and then you are able to debug > something. > >>>> > * when building IBP image we mount directory from the > host file > >>>> > system > >>>> > into mcollective container to make image build faster. > >>>> > * there are config files and some other files which > should be shared > >>>> > among containers which introduces unnecessary > complexity to the > >>>> > whole system. > >>>> > * our current delivery approach assumes we wrap into > rpm/deb > >>>> > packages > >>>> > every single piece of the Fuel system. Docker images > are not an > >>>> > exception. And as far as they depend on other rpm > packages we > >>>> > forced > >>>> > to build docker-images rpm package using kind of > specific build > >>>> > flow. Besides this package is quite big (300M). > >>>> > * I'd like it to be possible to install Fuel not from > ISO but from > >>>> > RPM > >>>> > repo on any rpm based distribution. But it is double > work to > >>>> > support > >>>> > both Docker based and package based approach. > >>>> > >>>> There is another point, the containers long build time when > installing > >>>> the master node. > >>>> > >>>> > > >>>> > Probably some of you can give other examples. Anyway, the > idea is to > >>>> > get > >>>> > rid of Docker containers on the master node and switch to > plane > >>>> > package > >>>> > based approach that we used before. > >>>> > > >>>> > As far as there is nothing new here, we just need to use > our old > >>>> > site.pp > >>>> > (with minimal modifications), it looks like it is possible to > >>>> > implement > >>>> > this during 8.0 release cycle. If there are no principal > objections, > >>>> > please give me a chance to do this ASAP (during 8.0), I > know it is a > >>>> > huge risk for the release, but still I think I can do this. > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > Vladimir Kozhukalov > >>>> > > >>>> > > >>>> > > >>>> > > > __________________________________________________________________________ > >>>> > OpenStack Development Mailing List (not for usage questions) > >>>> > Unsubscribe: > >>>> > > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > >>>> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>>> > > >>>> > >>>> > >>>> -- > >>>> Best regards, > >>>> Bogdan Dobrelya, > >>>> Irc #bogdando > >>>> > >>>> > >>>> > > __________________________________________________________________________ > >>>> OpenStack Development Mailing List (not for usage questions) > >>>> Unsubscribe: > >>>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> > >>> > >>> > >>> > >>> > > __________________________________________________________________________ > >>> OpenStack Development Mailing List (not for usage questions) > >>> Unsubscribe: > >>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> > >> > >> > >> > > __________________________________________________________________________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > > > > > -- > > Yours Faithfully, > > Vladimir Kuklin, > > Fuel Library Tech Lead, > > Mirantis, Inc. > > +7 (495) 640-49-04 <tel:%2B7%20%28495%29%20640-49-04> > > +7 (926) 702-39-68 <tel:%2B7%20%28926%29%20702-39-68> > > Skype kuklinvv > > 35bk3, Vorontsovskaya Str. > > Moscow, Russia, > > www.mirantis.com <http://www.mirantis.com> > > www.mirantis.ru <http://www.mirantis.ru> > > vkuk...@mirantis.com <mailto:vkuk...@mirantis.com> > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > > Kind Regards, > > Alexandr Kostrikov, > > > Mirantis, Inc. > > 35b/3, Vorontsovskaya St., 109147, Moscow, Russia > > > Tel.: +7 (495) 640-49-04 <tel:%2B7%20%28495%29%20640-49-04> > Tel.: +7 (925) 716-64-52 <tel:%2B7%20%28906%29%20740-64-79> > > Skype: akostrikov_mirantis > > E-mail:akostri...@mirantis.com <mailto:elogut...@mirantis.com> > > _www.mirantis.com <http://www.mirantis.ru/>__ > __www.mirantis.ru <http://www.mirantis.ru/>_ > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > > Timur, > Senior QA Engineer > OpenStack Projects > Mirantis Inc > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Bogdan Dobrelya, Irc #bogdando __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
