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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best regards, Bogdan Dobrelya, Irc #bogdando __________________________________________________________________________ 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