Open Stack

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 <emilien at 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 <greg at 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-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Emilien Macchi



-- 
Emilien Macchi