Vladimir
Although I am a big fan of this idea, I think it is too risky to do this
during our latest iteration for 8.0 release. There is a lot of stuff that
relies on our containerised approach. For example, it is our Fuel CI
master-node tests which will require adjustments. There are pieces of
things related to infrastructure for update repositories delivery and so on
and so forth. I would assess the risk of this change to break things and
block everything as high. So far, I suggest that if we provide a clear
deadline when such changes can get into master branch. I think, that we
should have all the code including CI jobs in place by Nov 30. Remember -
if CI is broken, our feature freeze is also broken. So I would suggest to
have a couple of days in advance before feature freeze to revert things.
On Thu, Nov 19, 2015 at 6:36 PM, Bogdan Dobrelya <bdobre...@mirantis.com>
wrote:
> 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
>
--
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuk...@mirantis.com
__________________________________________________________________________
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
