[openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node
Vladimir Sharshov
vsharshov at mirantis.com
Fri Nov 20 16:49:17 UTC 2015
+1 to remove docker in new CentOS 7.
On Fri, Nov 20, 2015 at 7:31 PM, Vladimir Kozhukalov <
vkozhukalov at mirantis.com> wrote:
> Bogdan,
>
> >> So, we could only deprecate the docker feature for the 8.0.
>
> 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).
>
> Guys,
>
> 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.
>
> 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.
>
>
>
>
> Vladimir Kozhukalov
>
> On Fri, Nov 20, 2015 at 6:47 PM, Bogdan Dobrelya <bdobrelia at mirantis.com>
> wrote:
>
>> 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
>>
>> __________________________________________________________________________
>> 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
>>
>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151120/e1bb06a0/attachment.html>
More information about the OpenStack-dev
mailing list