[openstack-dev] [kolla][kubernetes] Mirantis participation in kolla-mesos project and shift towards Kubernetes
michal.rostecki at gmail.com
Mon Apr 25 05:11:43 UTC 2016
On Mon, Apr 25, 2016 at 5:05 AM, Tomasz Pa <ss7pro at gmail.com> wrote:
> On Sat, Apr 23, 2016 at 2:27 AM, Steven Dake (stdake) <stdake at cisco.com> wrote:
>> Trying to understand the issue here, do you believe the current jinja2
>> Dockerfiles are not readable? I'm pretty sure my 11 and 13 year old
>> children which are just learning programming already understand conditionals
>> and variables. A full-blown DSL for describing container contents seems out
>> of the domain of Kolla's mission, although I'd never say no if someone
>> wanted to give a crack at implementing one.
> Kolla images are simply to big and not properly layered. What it means
> that if you today want to upgrade one of the packages: ie: python-nova
> (assuming images are build from RPMs) you're upgrading whole layer
> which contains all it's dependencies added by yum. So at the end
> simple 12MB upgrades turns to be 120MB (right now this is the size of
> the kolla image layer which contains python-nova).
If you want to upgrade the things in containers, you should just
rebuild them. You don't do any "yum update" action by hand in some
middle layer. The newest updated repo metadata come from the base
image and your layers on top of it are just installing packages as
So, the upgrade of python-nova package should come from new metadata
in base image, and then usual "yum install" in nova layer.
Upgrades of all unrelated packages in base system happen in the base image
> Having some proper DSL for describing container content would mean
> that we can have each package deployed within it's own image layer.
> This would definitely speed up upgrades and would ensure better layer
> sharing between multiple images.
Each package in it's own image layer? There will be no difference in
image size, but there will be an impact on readability and facility.
Of course I'm not criticizing the kolla repo-split idea here. I just
disagree with your argumentation, which in my opinion is even
unrelated to Sergey's and Jay's proposal.
More information about the OpenStack-dev