[openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node

Bogdan Dobrelya bdobrelia at mirantis.com
Fri Nov 20 15:47:17 UTC 2015


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
> <akostrikov at mirantis.com <mailto:akostrikov at 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
>     <ikalnitsky at mirantis.com <mailto:ikalnitsky at 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
>         <vkuklin at mirantis.com <mailto:vkuklin at 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
>         > <sgolovatiuk at mirantis.com <mailto:sgolovatiuk at mirantis.com>>
>         wrote:
>         >>
>         >> Hi,
>         >>
>         >> On Thu, Nov 19, 2015 at 5:50 PM, Matthew Mosesohn
>         <mmosesohn at mirantis.com <mailto:mmosesohn at 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
>         <bdobrelia at mirantis.com <mailto:bdobrelia at 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-request at lists.openstack.org?subject:unsubscribe
>         <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>         <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>         <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>         <http://OpenStack-dev-request@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>
>         > vkuklin at mirantis.com <mailto:vkuklin at mirantis.com>
>         >
>         >
>         __________________________________________________________________________
>         > OpenStack Development Mailing List (not for usage questions)
>         > Unsubscribe:
>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>         <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>         <http://OpenStack-dev-request@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:akostrikov at mirantis.com <mailto:elogutova at 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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando



More information about the OpenStack-dev mailing list