Open Stack

Hey Steven,

answers inline.

On Mon, Apr 25, 2016 at 9:27 AM, Steven Dake (stdake) <stdake at cisco.com> wrote:
>
> I disagree with your assertion.  You are gaming your data to provide the
> worst possible container (nova) because the RPMs pull in libvirt.  Kolla
> has no control over how Red Hat choses to package RDO, and at this time
> they choose to package libvirt as a dependency thereof.  Obviously it
> would be more optimal in a proper container system not to include libvirt
> in the dependencies installed with Nova.  If you really want that, use
> from source installs.  Then you could shave 1 minute off your upgrade time
> of a 64 node cluster.

Look here: http://paste.openstack.org/show/495459/ . As you can see
there're no libvirt dependencies there. It's only python-nova deps
there.
>
> A DSL does not solve this problem unless the DSL contains every dependency
> to install (from binary).  I don't see this as maintainable.

Agree being to detailed within the DSL can make the maintenance a
nightmare. I was thinking about some build automation which can
extract
dependencies (ie: repoquery --requires python-nova) and put each one
into a separate layer. We will just need a basic DSL with same
complexity as we have now in Dockerfiles which will be building
Dockerfiles dynamically.

Other approach could be setting a dedicated image for each of the
dependency and bind them together into the single image during build.

I'm also having Alpine linux in mind, this together with bazel can
make images really small.
>
> Just as a conclusion, deploying each dependency in a separate layer is an
> absolutely terrible idea.  Docker performance atleast is negatively
> affected by large layer counts, and aufs has a limit of 42 layers, so your
> idea is not viable asp resented.

This limit was 127 back in 2013.

-- 
Tomasz Paszkowski
SS7, Asterisk, SAN, Datacenter, Cloud Computing
+48500166299