[openstack-dev] [Fuel] Getting rid of Docker containers on the Fuel master node
Matthew Mosesohn
mmosesohn at mirantis.com
Mon Nov 23 12:33:29 UTC 2015
Bogdan brings up a good point. fuel-createmirror in its current state pulls
down an Ubuntu container and uses apt utilities inside. I know it's being
replaced, but it's one instance of an item that might be overlooked by this
process.
On Mon, Nov 23, 2015 at 3:27 PM, Bogdan Dobrelya <bdobrelia at mirantis.com>
wrote:
> 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
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151123/5b0e4dd9/attachment.html>
More information about the OpenStack-dev
mailing list