fuel-dev team mailing list archive

[Roman Zhnichkov <rzhnichkov@xxxxxxxxxxxx>]

Guys,
  official Docker web site <https://www.docker.io/learn_more/> states that
it is not production ready.

Why are we considering this solution for our carrier grade OpenStack life
cycle management tool?

--
Roman Zhnichkov



On Mon, Feb 10, 2014 at 11:25 AM, Roman Alekseenkov <
ralekseenkov@xxxxxxxxxxxx> wrote:

> Team,
>
> We know some of the Docker engineering folks. If you need to talk to them
> about best practices, please let me know.
>
> Roman
>
>
> On Mon, Feb 10, 2014 at 8:45 AM, Dmitry Ilyin <dilyin@xxxxxxxxxxxx> wrote:
>
>> 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
>>>
>>
>>
>> --
>> 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
>
>