Open Stack

Hello!

Thanks Greg for sharing your thoughts.  The idea of splitting off DIB
from OpenStack is new for me, therefore I collect some pros and
cons:

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. [1])
+ 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 [2] (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 [3]
  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 [6]; basic refactoring [7] 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
  need refactoring.

It is important to work on these topics to make DIB more attractive and
possible have more contributors.  Discussions about automated
development environment setup [4] or better developer tests [5] 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.

Kind regards

Andre


[1] https://imagefactory.otc.t-systems.com/
[2] https://github.com/florath/dib-element-raspberrypi3
[3] https://docs.openstack.org/developer/diskimage-builder/developer/index.html
[4] https://review.openstack.org/#/c/419655/
[5] https://review.openstack.org/#/c/414347/
[6] https://review.openstack.org/#/c/287784/
[7] https://review.openstack.org/#/c/319591/