Open Stack

On Sat, Mar 4, 2017, at 12:13 PM, Andre Florath wrote:
> 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.
> 

Ah, I may have not been super clear - I definitely agree that we
wouldn't want to move off of being hosted by OpenStack infra (for all
the reasons you list). There are actually two classes of project hosted
by OpenStack infra - OpenStack projects and OpenStack related projects
which have differing requirements
(https://docs.openstack.org/infra/manual/creators.html#decide-status-of-your-project).
What I've noticed is we tend to align more with the openstack-related
projects in terms of what we ask for / how we develop (e.g. not
following the normal release cycle, not really being a 'deliverable' of
an OpenStack release). AIUI though the distinction of whether you're an
official project team or a related project just distinguishes what
restrictions are placed on you, not whether you can be hosted by
OpenStack infra.

> 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, ...
> 
> 

Out of this list I think infra is really the only one which makes sense.
TripleO is the current setup and makes only slightly more sense than
Glance at this point: we'd be an odd appendage in both situations.
Having been in this situation for some time I tend to agree that it
isn't a big issue it tends to just be a mild annoyance every now and
then. IMO it'd be nice to resolve this issue once and for all, though
:).

> 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.

I cant agree more on all of this. TBH I think working on docs is
probably the most effective thing someone could do with DIB ATM because,
as you say, that's how you enable people to contribute. The theory is
that this is also what helps with the review latency - ask newer
contributors to help with initial reviews. That being said, I'd be
surprised if the large contributor count grows much unless some of the
use cases change simply because its very much a plumbing tool for many
of our consumers, not something people are looking to drive feature
development in to.

> 
> 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.
> 

+1

> 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/
>