fuel-dev team mailing list archive

[Roman Zhnichkov <rzhnichkov@xxxxxxxxxxxx>]

Guys,
  I believe you know what you are doing, but if you interested in opinion
of the guy who is actually doing delivery of the product that you
developing, here are my points:

   - the version that just released called 'quality', not 'production ready'
   - as I understand this software is focused on Ubuntu primarily and
   requires kernel 3.8 or later - how are we planning to deal with it assuming
   that a) now we are using Centos, b) some of our customers have hard
   requirements for Centos?
   - you absolutely have no control over this tool that is "under heavy
   development", it could be broken at any time
   - finally - there are a lot of risky technologies already in place in
   our product, why do we want to add new one?

Hope for your understanding.

Thank you.

--
Roman Zhnichkov



On Tue, Feb 11, 2014 at 6:43 AM, Vladimir Kuklin <vkuklin@xxxxxxxxxxxx>wrote:

> Roman,
>
> Docker is not production ready  as "hypervisor": for example, does not
> support (live) migration, good resource containment (e.g. Docker does not
> use some cgroup features) and so on. But we do not need these features. All
> we need is some type of containment and start/stop mechanism for our
> containers, that Docker already provides.
>
>
> On Tue, Feb 11, 2014 at 6:02 PM, Evgeniy L <eli@xxxxxxxxxxxx> wrote:
>
>> 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
>>>
>>>
>>
>> --
>> 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 <http://www.mirantis.ru/>
> www.mirantis.ru
> vkuklin@xxxxxxxxxxxx
>