Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151123/3ed0a8ea/attachment.html>