Open Stack

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