[openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node
Bogdan Dobrelya
bdobrelia at mirantis.com
Mon Nov 23 12:27:58 UTC 2015
On 23.11.2015 12:47, Aleksandr Maretskiy wrote:
> Hi all,
>
> as you know, Rally runs inside docker on Fuel master node, so docker
> removal (good improvement) is a problem for Rally users.
>
> To solve this, I'm planning to make native Rally installation on Fuel
> master node that is running on CentOS 7,
> and then make a step-by-step instruction how to make this installation.
>
> So I hope docker removal will not make issues for Rally users.
I believe the most backwards compatible scenario is to keep the docker
installed while removing the fuel-* docker things back to the host OS.
So nothing would prevent user from pulling and running whichever docker
containers he wants to put on the Fuel master node. Makes sense?
>
> On Mon, Nov 23, 2015 at 12:28 PM, Vladimir Kozhukalov
> <vkozhukalov at mirantis.com <mailto:vkozhukalov at mirantis.com>> wrote:
>
> ETA:
>
> experimental ISO w/o docker: tonight
> spec: tomorrow night
>
>
>
> Vladimir Kozhukalov
>
> On Mon, Nov 23, 2015 at 9:25 AM, Anastasia Urlapova
> <aurlapova at mirantis.com <mailto:aurlapova at mirantis.com>> wrote:
>
> @Vova,
> thanks for bringing this up.
> The new approach without docker containers on master node really
> has many advantages.
>
> @Igor,
> regarding your question, I would say that we have many
> dependencies from containers in CI/CD systems and test's
> codebase. The test alignment to the new implementation won't be
> easy. In such things we should move forward step by step.
> As you know the first step is a spec file, can you give us a
> link to it?
>
>
> Nastya.
>
> On Sat, Nov 21, 2015 at 6:10 AM, Oleg Gelbukh
> <ogelbukh at mirantis.com <mailto:ogelbukh at mirantis.com>> wrote:
>
> 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
> <tnurlygayanov at mirantis.com
> <mailto:tnurlygayanov at 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
> <akurilin at mirantis.com <mailto:akurilin at 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
> <vkozhukalov at mirantis.com
> <mailto: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://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
--
Best regards,
Bogdan Dobrelya,
Irc #bogdando
More information about the OpenStack-dev
mailing list