Open Stack

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