Please vote again: https://review.openstack.org/#/c/445617/
We keep dib-utils for now until we have a plan. On Tue, Mar 14, 2017 at 2:49 PM, Emilien Macchi <emil...@redhat.com> wrote: > Here's the proposal that will move DIB to Infra umbrella: > https://review.openstack.org/445617 > > Let's move forward and vote on this proposal. > > Thanks all, > > On Mon, Mar 6, 2017 at 3:23 PM, Gregory Haynes <g...@greghaynes.net> wrote: >> 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 > > > > -- > Emilien Macchi -- Emilien Macchi __________________________________________________________________________ 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