<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 4, 2017 at 6:13 PM, Andre Florath <span dir="ltr"><<a href="mailto:andre@florath.net" target="_blank">andre@florath.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
Thanks Greg for sharing your thoughts.  The idea of splitting off DIB<br>
from OpenStack is new for me, therefore I collect some pros and<br>
cons:<br>
<br>
Stay in OpenStack:<br>
<br>
+ Use available OpenStack infrastructure and methods<br>
+ OpenStack should include a possibility to create images for ironic,<br>
  VMs and docker. (Yes - there are others, but DIB is the best! :-) )<br>
+ Customers use DIB because it's part of OpenStack and for OpenStack<br>
  (see e.g. [1])<br>
+ Popularity of OpenStack attracts more developers than a separate<br>
  project (IMHO running DIB as a separate project even lowers the low<br>
  number of contributors).<br>
+ 'Short Distances' if there are special needs for OpenStack.<br>
+ Some OpenStack projects use DIB - and also use internal 'knowledge'<br>
  (like build-, run- or test-dependencies) - it would be not that easy<br>
  to completely separate this in short term.<br>
<br>
As a separate project:<br>
<br>
- Possibly less organizational overhead.<br>
- Independent releases possible.<br>
- Develop / include / concentrate also for / on other non-OpenStack<br>
  based virtualization platforms (EC2, Google Cloud, ...)<br>
- Extend the use cases to something like 'DIB can install a wide range<br>
  of Linux distributions on everything you want'.<br>
  Example: DIB Element to install Raspberry Pi [2] (which is currently<br>
  not the core use-case but shows how flexible DIB is).<br>
<br>
In my opinion the '+' arguments are more important, therefore DIB<br>
should stay within OpenStack as a sub-project.  I don't really care<br>
about the master: TripleO, Infra, glance, ...<br>
<br>
<br>
I want to touch an important point: Greg you are right that there are<br>
only a very few developers contributing for DIB.  One reason<br>
is IMHO, that it is not very attractive to work on DIB; some examples:<br>
<br>
o The documentation how to set up a DIB development environment [3]<br>
  is out of date.<br>
o Testing DIB is nightmare: a developer has no chance to test<br>
  as it is done in the CI (which is currently setup by other OpenStack<br>
  projects?). Round-trip times of ~2h - and then it often fails,<br>
  because of some mirror problem...<br>
o It takes sometimes very long until a patch is reviewed and merged<br>
  (e.g. still open since 1y1d [6]; basic refactoring [7] was filed<br>
  about 9 month ago and still not in the master).<br>
o There are currently about 100 elements in DIB. Some of them are<br>
  highly hardware dependent; some are known not to work; a lot of them<br>
  need refactoring.<br>
<br>
It is important to work on these topics to make DIB more attractive and<br>
possible have more contributors.  Discussions about automated<br>
development environment setup [4] or better developer tests [5] started<br>
but need more attention and discussions (and maybe a different setting<br>
than a patch / review).<br>
In addition we should concentrate on the core functionalities: block<br>
device setup, minimal system installation, bootloader, kernel and<br>
ramdisk creation and a stable extensible element interface; drop<br>
non-core elements or move them to the projects where they are used.<br>
<br>
Kind regards<br>
<br>
Andre<br>
<br>
<br>
[1] <a href="https://imagefactory.otc.t-systems.com/" rel="noreferrer" target="_blank">https://imagefactory.otc.t-<wbr>systems.com/</a><br>
[2] <a href="https://github.com/florath/dib-element-raspberrypi3" rel="noreferrer" target="_blank">https://github.com/florath/<wbr>dib-element-raspberrypi3</a><br>
[3] <a href="https://docs.openstack.org/developer/diskimage-builder/developer/index.html" rel="noreferrer" target="_blank">https://docs.openstack.org/<wbr>developer/diskimage-builder/<wbr>developer/index.html</a><br>
[4] <a href="https://review.openstack.org/#/c/419655/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/419655/</a><br>
[5] <a href="https://review.openstack.org/#/c/414347/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/414347/</a><br>
[6] <a href="https://review.openstack.org/#/c/287784/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/287784/</a><br>
[7] <a href="https://review.openstack.org/#/c/319591/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/319591/</a><br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div>Merging into infra sounds pragmatic, especially if a lack of testing / CI presence is an area that needs improvement. Yolanda from infra has been very active in DIB as of recent (in terms of CI).</div><div><br></div><div>Unless there are strong objections, infra seems a good choice of home to me. </div><div><br></div><div><br></div>
</div></div>