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

Aleksandr Maretskiy amaretskiy at mirantis.com
Mon Nov 23 11:47:42 UTC 2015


Hi all,

as you know, Rally runs inside docker on Fuel master node, so docker
removal (good improvement) is a problem for Rally users.

To solve this, I'm planning to make native Rally installation on Fuel
master node that is running on CentOS 7,
and then make a step-by-step instruction how to make this installation.

So I hope docker removal will not make issues for Rally users.

On Mon, Nov 23, 2015 at 12:28 PM, Vladimir Kozhukalov <
vkozhukalov at mirantis.com> wrote:

> ETA:
>
> experimental ISO w/o docker: tonight
> spec: tomorrow night
>
>
>
> Vladimir Kozhukalov
>
> On Mon, Nov 23, 2015 at 9:25 AM, Anastasia Urlapova <
> aurlapova at mirantis.com> wrote:
>
>> @Vova,
>> thanks for bringing this up.
>> The new approach without docker containers on master node really has many
>> advantages.
>>
>> @Igor,
>> regarding your question, I would say that we have many dependencies from
>> containers in CI/CD systems and test's codebase. The test alignment to the
>> new implementation won't be easy. In such things we should move forward
>> step by step.
>> As you know the first step is a spec file, can you give us a link to it?
>>
>>
>> Nastya.
>>
>> On Sat, Nov 21, 2015 at 6:10 AM, Oleg Gelbukh <ogelbukh at mirantis.com>
>> wrote:
>>
>>> With CentOS7 we will have python2.7 at Fuel Admin node as a default
>>> version, I believe.
>>>
>>> --
>>> Best regards,
>>> Oleg Gelbukh,
>>> Principal Engineer
>>> Mirantis
>>>
>>> On Fri, Nov 20, 2015 at 6:27 AM, Timur Nurlygayanov <
>>> tnurlygayanov at mirantis.com> wrote:
>>>
>>>> Hi Andrey,
>>>>
>>>> As far as I remember from the last usage of fuel master node, there was
>>>>> Centos + py26 installation. Python 2.6 is old enough and sometimes it is
>>>>> hard to launch some application on fuel node without docker (image with
>>>>> py27/py3). Are you planning to provide py27 at least or my note is outdated
>>>>> and I can already use py27 from the box?
>>>>
>>>> We can install docker on master node anyway to run Rally / Tempest or
>>>> other test suites and scripts from master node with Python 2.7 or something
>>>> also.
>>>>
>>>> On Fri, Nov 20, 2015 at 5:20 PM, Andrey Kurilin <akurilin at mirantis.com>
>>>> wrote:
>>>>
>>>>> Hi!
>>>>> I'm not fuel developer, so opinion below is based on user-view.
>>>>> As far as I remember from the last usage of fuel master node, there
>>>>> was Centos + py26 installation. Python 2.6 is old enough and sometimes it
>>>>> is hard to launch some application on fuel node without docker (image with
>>>>> py27/py3). Are you planning to provide py27 at least or my note is outdated
>>>>> and I can already use py27 from the box?
>>>>>
>>>>> On Thu, Nov 19, 2015 at 4:59 PM, Vladimir Kozhukalov <
>>>>> vkozhukalov at mirantis.com> 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. 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.
>>>>>>
>>>>>> 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,
>>>>> Andrey Kurilin.
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>> 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
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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
>>
>>
>
> __________________________________________________________________________
> 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/20151123/56b407de/attachment.html>


More information about the OpenStack-dev mailing list