fuel-dev team mailing list archive

[Evgeniy L <eli@xxxxxxxxxxxx>]

Hi Roman,

Yes it's true, but pay attention at their
criteria<http://blog.docker.io/2013/08/getting-to-docker-1-0/>of
production ready product also many companies already use it in
production. And recently they
introduced<http://blog.docker.io/2014/02/docker-0-8-quality-new-builder-features-btrfs-storage-osx-support/>
quality
release.
Anyway I think it's better to use docker than reinventing the wheel and to
implement our own "production ready" container management system in several
month.

Thanks


On Tue, Feb 11, 2014 at 3:25 PM, Roman Zhnichkov <rzhnichkov@xxxxxxxxxxxx>wrote:

> 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
>>
>>
>
> --
> 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
>
>