[openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder
emilien at redhat.com
Tue Mar 14 18:49:55 UTC 2017
Here's the proposal that will move DIB to Infra umbrella:
Let's move forward and vote on this proposal.
On Mon, Mar 6, 2017 at 3:23 PM, Gregory Haynes <greg at greghaynes.net> wrote:
> On Sat, Mar 4, 2017, at 12:13 PM, Andre Florath wrote:
>> Thanks Greg for sharing your thoughts. The idea of splitting off DIB
>> from OpenStack is new for me, therefore I collect some pros and
>> 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. )
>> + 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
> 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  (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 
>> 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 ; basic refactoring  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  or better developer tests  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
>>  https://imagefactory.otc.t-systems.com/
>>  https://github.com/florath/dib-element-raspberrypi3
>>  https://review.openstack.org/#/c/419655/
>>  https://review.openstack.org/#/c/414347/
>>  https://review.openstack.org/#/c/287784/
>>  https://review.openstack.org/#/c/319591/
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev