[openstack-dev] [infra][diskimage-builder] containers, Containers, CONTAINERS!

Paul Belanger pabelanger at redhat.com
Fri Jan 6 15:57:46 UTC 2017


On Fri, Jan 06, 2017 at 09:48:31AM +0100, Andre Florath wrote:
> Hello Paul,
> 
> thank you very much for your contribution - it is very appreciated.
> 
> You addressed a topic with your patch set that was IMHO not in a wide
> focus: generating images for containers.  The ideas in the patches are
> good and should be implemented.
> 
> Nevertheless I'm missing the concept behind your patches. What I saw
> are a couple of (independent?) patches - and it looks that there is
> one 'big goal' - but I did not really get it.  My proposal is (as it
> is done for other bigger changes or introducing new concepts) that
> you write a spec for this first [1].  That would help other people
> (see e.g. Matthew) to use the same blueprint also for other
> distributions.
Sure, I can write a spec if needed but the TL;DR is:

Use diskimage-builder to build debootstrap --variant=minbase chroot, and nothing
else. So I can then use take the generated tarball and do something else with
it.

> One possibility would be to classify different element sets and define
> the dependency between them.  E.g. to have a element class 'container'
> which can be referenced by other classes, but is not able to reference
> these (e.g. VM or hardware specific things).
> 
> There are additional two major points:
> 
> * IMHO you addressed only some elements that needs adaptions to be
>   able to used in containers.  One element I stumbled over yesterday
>   is the base element: it is always included until you explicitly
>   exclude it.  This base element depends on a complete init-system -
>   which is for a container unneeded overhead. [2]

Correct, for this I simply pass the -n flag to disk-image-create. This removes
the need for include the base element. If we want to make a future optimization
to remove or keep, I am okay with that. But the main goal for me is to include
the new ubuntu-rootfs element with minimal disruption as possible.
> 
> * Your patches add a lot complexity and code duplication.
>   This is not the way it should be (see [3], p 110, p 345).
The main reason this was done, is yes there is some code duplication, but the
because, this is done in the root.d phase.  Moving this logic into another
phase, then requires the need to install python into chroot, and then dpkg,
dib-python, package-install, etc. This basically contaminants the pristine
debootstrap environment, something I am trying hard not to do. I figure, 2 lines
to delete stale data is fine.  However, if there is an objection, we can remove
it.  Keep in mind, by deleting the cache we get the tarball size to 42Mb (down
from 79Mb).

>   One reason is, that you do everything twice: once for Debian and
>   once for Ubuntu - and both in a (slightly) different way.
Yes, sadly the debian elements came along after the ubuntu-minimal elements,
with different people writing the code. For the most part, I've been trying to
condense the code path between the 2, but we are slowly getting there.

As you can see, the debian-rootfs element does now work correctly[6] based on
previous patches in the stack.

However, I don't believe this is the stack to make things better between the 2
flavors. We can use the existing ubuntu-minimal and debian-minimal elements and
iterate atop of that.  One next steps is to address how we handle the
sources.list file, between ubuntu and debian we do things differently.

[6] https://review.openstack.org/#/c/414765/

>   Please: factor out common code.
>   Please: improve code as you touch it.
> 
> And three minor:
> 
> * Release notes are missing (reno is your friend)
> 
Sure, I can add release notes.

> * Please do not introduce code which 'later on' can / should / will be
>   cleaned up.  Do it correct right from the beginning. [4]
> 
I can rebase code if needed.

> * It looks that this is a bigger patch set - so maybe we should
>   include it in v2?
> 
I'm not sure we need to wait for v2 (but I am biased).  I've recently revamped
our testing infra for diskimage-builder. We now build images, along with
launching them with nodepool and SSHing into them.

Side note, when is v2 landing?  I know there has been issues with tripleo.

> Kind regards
> 
> Andre
> 
> 
> [1] https://review.openstack.org/#/c/414728/
> [2] https://review.openstack.org/#/c/417310/
> [3] "Refactoring - Improving the Design of Existing Code", Martin
>     Fowler, Addison Wesley, Boston, 2011
> [4] https://review.openstack.org/#/c/414728/8/elements/debootstrap-minimal/root.d/99-clean-up-cache
> [5] https://review.openstack.org/#/c/413221/
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list