[openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder
andre at florath.net
Sat Mar 4 18:13:12 UTC 2017
Thanks Greg for sharing your thoughts. The idea of splitting off DIB
from OpenStack is new for me, therefore I collect some pros and
Stay in OpenStack:
+ Use available OpenStack infrastructure and methods
+ OpenStack should include a possibility to create images for ironic,
VMs and docker. (Yes - there are others, but DIB is the best! :-) )
+ Customers use DIB because it's part of OpenStack and for OpenStack
(see e.g. )
+ Popularity of OpenStack attracts more developers than a separate
project (IMHO running DIB as a separate project even lowers the low
number of contributors).
+ 'Short Distances' if there are special needs for OpenStack.
+ Some OpenStack projects use DIB - and also use internal 'knowledge'
(like build-, run- or test-dependencies) - it would be not that easy
to completely separate this in short term.
As a separate project:
- Possibly less organizational overhead.
- Independent releases possible.
- Develop / include / concentrate also for / on other non-OpenStack
based virtualization platforms (EC2, Google Cloud, ...)
- Extend the use cases to something like 'DIB can install a wide range
of Linux distributions on everything you want'.
Example: DIB Element to install Raspberry Pi  (which is currently
not the core use-case but shows how flexible DIB is).
In my opinion the '+' arguments are more important, therefore DIB
should stay within OpenStack as a sub-project. I don't really care
about the master: TripleO, Infra, glance, ...
I want to touch an important point: Greg you are right that there are
only a very few developers contributing for DIB. One reason
is IMHO, that it is not very attractive to work on DIB; some examples:
o The documentation how to set up a DIB development environment 
is out of date.
o Testing DIB is nightmare: a developer has no chance to test
as it is done in the CI (which is currently setup by other OpenStack
projects?). Round-trip times of ~2h - and then it often fails,
because of some mirror problem...
o It takes sometimes very long until a patch is reviewed and merged
(e.g. still open since 1y1d ; basic refactoring  was filed
about 9 month ago and still not in the master).
o There are currently about 100 elements in DIB. Some of them are
highly hardware dependent; some are known not to work; a lot of them
It is important to work on these topics to make DIB more attractive and
possible have more contributors. Discussions about automated
development environment setup  or better developer tests  started
but need more attention and discussions (and maybe a different setting
than a patch / review).
In addition we should concentrate on the core functionalities: block
device setup, minimal system installation, bootloader, kernel and
ramdisk creation and a stable extensible element interface; drop
non-core elements or move them to the projects where they are used.
More information about the OpenStack-dev