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/ > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev