Open Stack

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.

Thank you!


On Fri, Nov 20, 2015 at 4:44 PM, Alexander Kostrikov <
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>
> 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>
>> 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> wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Thu, Nov 19, 2015 at 5:50 PM, Matthew Mosesohn <
>> 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>
>> >>> 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://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
>> >>>
>> >>
>> >>
>> >>
>> __________________________________________________________________________
>> >> 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
>> >>
>> >
>> >
>> >
>> > --
>> > Yours Faithfully,
>> > Vladimir Kuklin,
>> > Fuel Library Tech Lead,
>> > Mirantis, Inc.
>> > +7 (495) 640-49-04
>> > +7 (926) 702-39-68
>> > Skype kuklinvv
>> > 35bk3, Vorontsovskaya Str.
>> > Moscow, Russia,
>> > www.mirantis.com
>> > www.mirantis.ru
>> > vkuklin at mirantis.com
>> >
>> >
>> __________________________________________________________________________
>> > 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
>>
>
>
>
> --
>
> Kind Regards,
>
> Alexandr Kostrikov,
>
> Mirantis, Inc.
>
> 35b/3, Vorontsovskaya St., 109147, Moscow, Russia
>
>
> Tel.: +7 (495) 640-49-04
> Tel.: +7 (925) 716-64-52 <%2B7%20%28906%29%20740-64-79>
>
> Skype: akostrikov_mirantis
>
> E-mail: akostrikov at mirantis.com <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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Timur,
Senior QA Engineer
OpenStack Projects
Mirantis Inc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151120/95c3974b/attachment.html>