fuel-dev team mailing list archive

[Dmitry Ilyin <dilyin@xxxxxxxxxxxx>]

Let's try to use this http://www.packer.io/docs/builders/docker.html it
integrates well with both docker and puppet


2014-02-10 Matthew Mosesohn <mmosesohn@xxxxxxxxxxxx>:

> I'm not trying to go in that direction. I'm trying to build single
> containers that run puppet... like a single class that runs classes
> nailgun, nailgun::user, nailgun::venv, and nailgun::supervisor without
> ostf, naily, postgres, etc for isolation.
>
> Yes, we may end up using some puppet manifests to orchestrate upgrades
> just because there are a few providers that can do this. Starting and
> stopping containers involves running commands and grabbing the
> generated IDs and a bash script may not be the most elegant method. We
> should use a smart tool that is atomic and can fail where we need it
> and provide useful feedback.
>
> On Mon, Feb 10, 2014 at 6:41 PM, Vladimir Kuklin <vkuklin@xxxxxxxxxxxx>
> wrote:
> > Matt
> >
> > You can easily rewrite puppet modules by writing Puppet provider for
> Docker
> > exec and applying puppet defaults class by class: e.g:
> >
> > Exec {provider=>Docker, ENV=>"export container_id=#{ID}"}
> >
> >
> > On Mon, Feb 10, 2014 at 5:36 PM, Bogdan Dobrelya <bdobrelia@xxxxxxxxxxxx
> >
> > wrote:
> >>
> >> On 02/10/2014 03:07 PM, Dmitry Ilyin wrote:
> >> > Actually it's a very promising idea to move to atomic lxc container
> for
> >> > our master node.
> >> >
> >> > Volumes used to run these containers could be packaged and easily
> >> > installed or updated by just replacing the file by the new version.
> >> > Container will also be compleatly independent and any changing would
> not
> >> > break any neighbour container. (Well... except database structures...)
> >> >
> >> > Such containers will be able to speak to each other through unix or
> tcp
> >> > sockets.
> >> > Building such containers will require us to invent some automated
> system
> >> > but their installation and use would be much more reliable then our
> >> > current technology.
> >> > This method can also combine configuration flexibility of
> >> > puppet-deployed nodes with speed and reliability of image-based
> >> > provisioned systems.
> >> >
> >> > We should also look into using the same approach for controller and
> even
> >> > compute nodes. It could help us to find solution to our long lasting
> >> > OpenStack upgrading problem.
> >> AFIK, the main issue of Openstack upgrades is DB schema related (all
> >> objects must have a versioning info, see
> >> https://blueprints.launchpad.net/nova/+spec/unified-object-model, for
> >> example). I doubt docker could help here. Please correct me, If I'm
> wrong.
> >> >
> >> >
> >> > 2014-02-10 Evgeniy L <eli@xxxxxxxxxxxx <mailto:eli@xxxxxxxxxxxx>>:
> >> >
> >> >     Hi,
> >> >
> >> >
> >> >     As many of you may already know we started design/implementation
> of
> >> >     master node upgrade feature. Here you can read the design document
> >> >
> >> > <
> https://docs.google.com/a/mirantis.com/document/d/1Mem9LP7ysaHNNSltlCLPw36jHix5ULlKmsMgTViHfog/
> >.
> >> >
> >> >
> >> >     So, it's just status update of this feature.
> >> >
> >> >     We want to use docker as containers management tool.
> >> >
> >> >
> >> >     *Here is Docker's pros and cons*
> >> >
> >> >     Pros
> >> >
> >> >     +
> >> >
> >> >
> http://stackoverflow.com/questions/17989306/what-does-docker-add-to-just-plain-lxc
> >> >
> >> >     + rest API (it will be very useful in case of plugins, when we'll
> be
> >> >     able to setup new container from inside another container)
> >> >
> >> >     + lxc requires us to design our own build process and networking
> >> >
> >> >     + docker has a standard dockerfile format and tools to build
> images
> >> >     and store them in git and do version management
> >> >
> >> >     Cons
> >> >
> >> >     - additional complexity
> >> >
> >> >     - non-persistent containers, it can be solved with volumes
> >> >
> >> >
> >> >
> http://www.tech-d.net/2013/12/16/persistent-volumes-with-docker-container-as-volume-pattern/
> >> >
> >> >
> >> >
> http://www.offermann.us/2013/12/tiny-docker-pieces-loosely-joined.html
> >> >
> >> >     http://crosbymichael.com/advanced-docker-volumes.html
> >> >
> >> >     - regarding non-persistent containers will be a lot of questions
> >> >     like "I patched nailgun but when I rerun container all changes are
> >> >     gone" (can be solved with documentation)
> >> >
> >> >
> >> >     Let us know if you have any ideas or questions.
> >> >
> >> >     Thanks
> >> >
> >> >     --
> >> >     Mailing list: https://launchpad.net/~fuel-dev
> >> >     Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >> >     <mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>
> >> >     Unsubscribe : https://launchpad.net/~fuel-dev
> >> >     More help   : https://help.launchpad.net/ListHelp
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >> --
> >> Best regards,
> >> Bogdan Dobrelya,
> >> Skype #bogdando_at_yahoo.com
> >> Irc #bogdando
> >>
> >> --
> >> Mailing list: https://launchpad.net/~fuel-dev
> >> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~fuel-dev
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
> >
> > --
> > Yours Faithfully,
> > Vladimir Kuklin,
> > Senior Deployment Engineer,
> > Mirantis, Inc.
> > +7 (495) 640-49-04
> > +7 (926) 702-39-68
> > Skype kuklinvv
> > 45bk3, Vorontsovskaya Str.
> > Moscow, Russia,
> > www.mirantis.com
> > www.mirantis.ru
> > vkuklin@xxxxxxxxxxxx
> >
> > --
> > Mailing list: https://launchpad.net/~fuel-dev
> > Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~fuel-dev
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>