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 <
tnurlygaya...@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 <akuri...@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 <
>> vkozhuka...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
