Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Emilien Macchi]

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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Emilien Macchi]

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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Gregory Haynes]

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] 

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Luke Hinds]

On Sat, Mar 4, 2017 at 6: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.
>
> 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, ...
>
>
> 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.
>
> 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.
>
> 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
>


Merging into infra sounds pragmatic, especially if a lack of testing / CI
presence is an area that needs improvement. Yolanda from infra has been
very active in DIB as of recent (in terms of CI).

Unless there are strong objections, infra seems a good choice of home to
me.
__
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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Ligong LG1 Duan]

I agree that the idea of DIB's becoming a component of Glance is a little crazy 
and there is big difference between creating images and storing them.
My initial thought on this is to create an ecosystem of images, where user can 
do anything that are related to images. Since Glance is a well-known project 
for storing images, it might be a good place to implement that.
I would be prefer DIB to be an independent project if it is impossible to 
become a part of Glance.

Regards,
Ligong Duan
 

-Original Message-
From: Ben Nemec [mailto:openst...@nemebean.com] 
Sent: Saturday, March 04, 2017 3:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tripleo][diskimage-builder] Status of 
diskimage-builder



On 03/03/2017 03:25 AM, Ligong LG1 Duan wrote:
> I am wondering whether DIB can become a component of Glance, as DIB is used 
> to create OS images and Glance to upload OS images.

I see a big difference between creating images and storing them.  I can't 
imagine Glance would have any interest in owning dib, nor do I think they 
should.

__
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

__
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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Andre Florath]

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.

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


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.

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.

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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Jeremy Stanley]

On 2017-03-03 13:27:16 -0600 (-0600), Gregory Haynes wrote:
[...]
> I hadn't heard anything to the effect of infra not wanting us, but
> AFAIK none of us has stepped up to really ask. One issue with
> infra is that, typically, OpenStack projects do not depend
> directly on infra projects. I am sure others have a better idea of
> the pitfalls here. OTOH we have a pretty large shared set of
> knowledge between DIB and infra which makes this option fairly
> attractive.
[...]

While it may not be a perfect match, we can probably make it work if
that's a route you're interested in going. If nothing else, there's
a fair amount of overlap between the people working on DIB and on
general Infra-oriented tooling.
-- 
Jeremy Stanley

__
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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Gregory Haynes]

Hello,

Thanks for bringing this back to life.

As I am sure some are aware I have been mostly absent from DIB lately,
so don't let me stop you all from going forward with this or any of the
other plans. I just wanted to do a bit of a braindump on my thought
process from a while back on why I never went through with trying to
become an independent openstack project team.

The main issue that prevented me from going forward with this was that I
worried we were too small for it to work effectively.  IME DIB tends to
have a fair amount of drive by contributors and a very small (roughly
2-3)  set of main contributors who are very part-time and who certainly
aren't primarily focused on DIB (or even upstream OpenStack).
Fortunately, I think the project does fine with this setup: The number
of new features scales up or down to meet our contributor capacity and
we haven't required a ton of firefighting in recent memory. Not only
that, we actually seem to be extremely stable in this setup which is
great given how we can break many other projects in ways which are non
trivial to debug.

Our low contributor capacity does pose some problems when you try to
become an OpenStack project team though. Firstly, someone needs to agree
to be PTL and, essentially, take the responsibilities seriously [1]. In
addition to the issue of having someone willing to do this, I worried
that the responsibilities would take up a non trivial amount of time
(for our low activity project) which previously went to other tasks
keeping the project afloat. I also was not sure we would be doing anyone
any favors if a cycle or two down the road we ended up in a spot where
no one is interested in running for PTL even though the project itself
is doing fine. Maybe some of the TC folks can correct me if i'm wrong
but that seems to create a fair bit of churn where a decision has to be
made on whether to attic the project or do something else like appoint a
PTL.

All that to say - If we decide to go the route of becoming on
independent openstack project would we have someone willing to be PTL
and do we think that would be an effective use of our time?



WRT us being consumed by glance or infra - I think either of these could
work. I hadn't heard anything to the effect of infra not wanting us, but
AFAIK none of us has stepped up to really ask. One issue with infra is
that, typically, OpenStack projects do not depend directly on infra
projects. I am sure others have a better idea of the pitfalls here. OTOH
we have a pretty large shared set of knowledge between DIB and infra
which makes this option fairly attractive.

My primary concern with glance is that AFAIK the only relation we've had
historically is the word 'image' in our project description. That is to
say, I don't know of any shared knowledge between the contributor base.
As a result I am not really a fan of this option.

For both of these its not really an issue of whether we'd like to 'own'
the project IMO (its all the same open source project after all, we
don't own it). It's mostly a matter of whether its technically feasible
(e.g. are there issues with infra due to things like dependencies) and
whether it makes any sense from a collaboration standpoint (otherwise
we'll end up right back where we are but with another parent project
team).



I'd like to propose a third option which I think may be best - We could
become an independent non-openstack project hosted by openstack infra.
This would allow us to effectively continue operating as we do today
which is IMO ideal. Furthermore, this would resolve some of the issues
we've had relating to the release process where we desired to be
release:independent and tag our own releases (we would no longer be of
the release team's concern rather than need to be special cased). I feel
like we've been effectively operating in this manner (a non openstack
independent project) so it seems a natural fit to me. Hopefully some of
the more openstack-process enlightened can chime in confirming that this
is doable and ok or if theres some big issues I am missing here...


HTH,
Greg

--

1: https://docs.openstack.org/project-team-guide/ptl.html


On Thu, Mar 2, 2017, at 03:31 PM, Emilien Macchi wrote:
> On Thu, Jan 12, 2017 at 3:06 PM, Yolanda Robla Mota 
> wrote:
> > From my point of view, i've been using that either on infra with
> > puppet-infracloud, glean.. and now with TripleO. So in my opinion, it shall
> > be an independent project, with core contributors from both sides.
> >
> > On Thu, Jan 12, 2017 at 8:51 PM, Paul Belanger 
> > wrote:
> >>
> >> On Thu, Jan 12, 2017 at 02:11:42PM -0500, James Slagle wrote:
> >> > On Thu, Jan 12, 2017 at 1:55 PM, Emilien Macchi 
> >> > wrote:
> >> > > On Thu, Jan 12, 2017 at 12:06 PM, Paul Belanger
> >> > >  wrote:
> >> > >> Greetings,
> >> > >>
> >> > >> With the containerization[1] of tripleo, I'd like to know more about
> >> > >> 

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Ben Nemec]

On 03/03/2017 03:25 AM, Ligong LG1 Duan wrote:

I am wondering whether DIB can become a component of Glance, as DIB is used to 
create OS images and Glance to upload OS images.


I see a big difference between creating images and storing them.  I 
can't imagine Glance would have any interest in owning dib, nor do I 
think they should.


__
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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Ben Nemec]

On 03/02/2017 03:31 PM, Emilien Macchi wrote:

On Thu, Jan 12, 2017 at 3:06 PM, Yolanda Robla Mota  wrote:

From my point of view, i've been using that either on infra with
puppet-infracloud, glean.. and now with TripleO. So in my opinion, it shall
be an independent project, with core contributors from both sides.

On Thu, Jan 12, 2017 at 8:51 PM, Paul Belanger 
wrote:


On Thu, Jan 12, 2017 at 02:11:42PM -0500, James Slagle wrote:

On Thu, Jan 12, 2017 at 1:55 PM, Emilien Macchi 
wrote:

On Thu, Jan 12, 2017 at 12:06 PM, Paul Belanger
 wrote:

Greetings,

With the containerization[1] of tripleo, I'd like to know more about
the future of
diskimage-builder as it relates to the tripleo project.

Reading the recently approved spec for containers, container (image)
builds are
no longer under the control of tripleo; by kolla. Where does this
leave
diskimage-builder as a project under tripleo?  I specifically ask,
because I'm
wanting to start down the path of using diskimage-builder as an
interface to
containers.

Basically, is it time to move diskimage-builder out from the tripleo
project
into another, or its own? Or is tripleo wanting to more forward on
development
efforts on diskimage-builder.


Looking at stats on who is actively contributing into DIB:
http://stackalytics.com/?module=diskimage-builder

It seems that we have some folks from infra and some folks on dib
only, and a few contributors from TripleO.

I guess the best option is to ask DIB contributors: do you want to own
the project you're committing to?
If not, is it something that should stay in TripleO (imo no) or move
into openstack-infra (imo yes, if infra agrees).

With my PTL hat, I'm really open to this thing and I wouldn't mind to
transfer ownership to another group.


I was under the impression it was already it's own project team based
on:
http://lists.openstack.org/pipermail/openstack-dev/2016-July/099805.html

It looks like the change was never made in governance however.


Yes, it just looks like Greg created new core reviewers, not officially
breaking
away from tripleo.

If everybody is on board with moving diskimage-builder outside of tripleo,
we
need to decided where it lives. Two options come to mind:

1) Move diskimage-builder into own (big tent?) project. Setup a new PTL,
etc.


Let's move forward with this one if everybody agrees on that.

DIB folks: please confirm on this thread that you're ok to move out
DIB from TripleO and be an independent project.
Also please decide if we want it part of the Big Tent or not (it will
require a PTL).


I was +1 on splitting the review team out and I'm +1 on making it a 
completely separate project.  It's already functioning as one anyway, 
with its own meeting and IRC channel.





2) Move diskimage-builder into openstack-infra (fungi PTL).


I don't think Infra wants to carry this one.


3) Keep diskimage-builder under tripleo (EmilienM PTL).


We don't want to carry this one anymore for the reasons mentioned in
that thread.


Thoughts?


The reason I -1'd Paul's TripleO spec and suggested it be proposed to
diskimage-builder was due to:
http://lists.openstack.org/pipermail/openstack-dev/2016-June/098560.html
and
https://review.openstack.org/#/c/336109/

I just want to make sure the right set of reviewers who are driving
dib development see the spec proposal.

--
-- James Slagle
--


__
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


__
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





--
Yolanda Robla Mota
NFV Partner Engineer
yrobl...@redhat.com
+34 605641639

__
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







__
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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Ligong LG1 Duan]

I am wondering whether DIB can become a component of Glance, as DIB is used to 
create OS images and Glance to upload OS images.

Regards,
Ligong Duan 

-Original Message-
From: Matthew Thode [mailto:prometheanf...@gentoo.org] 
Sent: Friday, March 03, 2017 9:36 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [tripleo][diskimage-builder] Status of 
diskimage-builder

On 03/02/2017 03:31 PM, Emilien Macchi wrote:
>>> 1) Move diskimage-builder into own (big tent?) project. Setup a new 
>>> PTL, etc.
> Let's move forward with this one if everybody agrees on that.
> 
> DIB folks: please confirm on this thread that you're ok to move out 
> DIB from TripleO and be an independent project.
> Also please decide if we want it part of the Big Tent or not (it will 
> require a PTL).
> 
>>> 2) Move diskimage-builder into openstack-infra (fungi PTL).
> I don't think Infra wants to carry this one.
> 
>>> 3) Keep diskimage-builder under tripleo (EmilienM PTL).
> We don't want to carry this one anymore for the reasons mentioned in 
> that thread.
> 

As a sometimes contributor to DIB for Gentoo stuff I'm fine with moving it out 
into it's own project under the big tent, with a PTL and all.

--
Matthew Thode (prometheanfire)


__
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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Simon Leinen]

Emilien Macchi writes:
> DIB folks: please confirm on this thread that you're ok to move out
> DIB from TripleO and be an independent project.

As a DIB user (and occasional contributor of patches in the past) and
TripleO non-user, I'm in favor of the separation.

> Also please decide if we want it part of the Big Tent or not (it will
> require a PTL).

No opinion.
-- 
Simon.

__
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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Yolanda Robla Mota]

As user and contributor for diskimage-builder, i think that being an
independent project, and moving to the big tent, will benefit it. +1 from
my side

On Fri, Mar 3, 2017 at 2:35 AM, Matthew Thode 
wrote:

> On 03/02/2017 03:31 PM, Emilien Macchi wrote:
> >>> 1) Move diskimage-builder into own (big tent?) project. Setup a new
> PTL,
> >>> etc.
> > Let's move forward with this one if everybody agrees on that.
> >
> > DIB folks: please confirm on this thread that you're ok to move out
> > DIB from TripleO and be an independent project.
> > Also please decide if we want it part of the Big Tent or not (it will
> > require a PTL).
> >
> >>> 2) Move diskimage-builder into openstack-infra (fungi PTL).
> > I don't think Infra wants to carry this one.
> >
> >>> 3) Keep diskimage-builder under tripleo (EmilienM PTL).
> > We don't want to carry this one anymore for the reasons mentioned in
> > that thread.
> >
>
> As a sometimes contributor to DIB for Gentoo stuff I'm fine with moving
> it out into it's own project under the big tent, with a PTL and all.
>
> --
> Matthew Thode (prometheanfire)
>
>
> __
> 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
>
>


-- 
Yolanda Robla Mota
NFV Partner Engineer
yrobl...@redhat.com
+34 605641639
__
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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Matthew Thode]

On 03/02/2017 03:31 PM, Emilien Macchi wrote:
>>> 1) Move diskimage-builder into own (big tent?) project. Setup a new PTL,
>>> etc.
> Let's move forward with this one if everybody agrees on that.
> 
> DIB folks: please confirm on this thread that you're ok to move out
> DIB from TripleO and be an independent project.
> Also please decide if we want it part of the Big Tent or not (it will
> require a PTL).
> 
>>> 2) Move diskimage-builder into openstack-infra (fungi PTL).
> I don't think Infra wants to carry this one.
> 
>>> 3) Keep diskimage-builder under tripleo (EmilienM PTL).
> We don't want to carry this one anymore for the reasons mentioned in
> that thread.
> 

As a sometimes contributor to DIB for Gentoo stuff I'm fine with moving
it out into it's own project under the big tent, with a PTL and all.

-- 
Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature
__
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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Emilien Macchi]

On Thu, Jan 12, 2017 at 3:06 PM, Yolanda Robla Mota  wrote:
> From my point of view, i've been using that either on infra with
> puppet-infracloud, glean.. and now with TripleO. So in my opinion, it shall
> be an independent project, with core contributors from both sides.
>
> On Thu, Jan 12, 2017 at 8:51 PM, Paul Belanger 
> wrote:
>>
>> On Thu, Jan 12, 2017 at 02:11:42PM -0500, James Slagle wrote:
>> > On Thu, Jan 12, 2017 at 1:55 PM, Emilien Macchi 
>> > wrote:
>> > > On Thu, Jan 12, 2017 at 12:06 PM, Paul Belanger
>> > >  wrote:
>> > >> Greetings,
>> > >>
>> > >> With the containerization[1] of tripleo, I'd like to know more about
>> > >> the future of
>> > >> diskimage-builder as it relates to the tripleo project.
>> > >>
>> > >> Reading the recently approved spec for containers, container (image)
>> > >> builds are
>> > >> no longer under the control of tripleo; by kolla. Where does this
>> > >> leave
>> > >> diskimage-builder as a project under tripleo?  I specifically ask,
>> > >> because I'm
>> > >> wanting to start down the path of using diskimage-builder as an
>> > >> interface to
>> > >> containers.
>> > >>
>> > >> Basically, is it time to move diskimage-builder out from the tripleo
>> > >> project
>> > >> into another, or its own? Or is tripleo wanting to more forward on
>> > >> development
>> > >> efforts on diskimage-builder.
>> > >
>> > > Looking at stats on who is actively contributing into DIB:
>> > > http://stackalytics.com/?module=diskimage-builder
>> > >
>> > > It seems that we have some folks from infra and some folks on dib
>> > > only, and a few contributors from TripleO.
>> > >
>> > > I guess the best option is to ask DIB contributors: do you want to own
>> > > the project you're committing to?
>> > > If not, is it something that should stay in TripleO (imo no) or move
>> > > into openstack-infra (imo yes, if infra agrees).
>> > >
>> > > With my PTL hat, I'm really open to this thing and I wouldn't mind to
>> > > transfer ownership to another group.
>> >
>> > I was under the impression it was already it's own project team based
>> > on:
>> > http://lists.openstack.org/pipermail/openstack-dev/2016-July/099805.html
>> >
>> > It looks like the change was never made in governance however.
>> >
>> Yes, it just looks like Greg created new core reviewers, not officially
>> breaking
>> away from tripleo.
>>
>> If everybody is on board with moving diskimage-builder outside of tripleo,
>> we
>> need to decided where it lives. Two options come to mind:
>>
>> 1) Move diskimage-builder into own (big tent?) project. Setup a new PTL,
>> etc.

Let's move forward with this one if everybody agrees on that.

DIB folks: please confirm on this thread that you're ok to move out
DIB from TripleO and be an independent project.
Also please decide if we want it part of the Big Tent or not (it will
require a PTL).

>> 2) Move diskimage-builder into openstack-infra (fungi PTL).

I don't think Infra wants to carry this one.

>> 3) Keep diskimage-builder under tripleo (EmilienM PTL).

We don't want to carry this one anymore for the reasons mentioned in
that thread.

>> Thoughts?
>>
>> > The reason I -1'd Paul's TripleO spec and suggested it be proposed to
>> > diskimage-builder was due to:
>> > http://lists.openstack.org/pipermail/openstack-dev/2016-June/098560.html
>> > and
>> > https://review.openstack.org/#/c/336109/
>> >
>> > I just want to make sure the right set of reviewers who are driving
>> > dib development see the spec proposal.
>> >
>> > --
>> > -- James Slagle
>> > --
>> >
>> >
>> > __
>> > 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
>>
>> __
>> 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
>
>
>
>
> --
> Yolanda Robla Mota
> NFV Partner Engineer
> yrobl...@redhat.com
> +34 605641639
>
> __
> 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

__
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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Yolanda Robla Mota]

>From my point of view, i've been using that either on infra with
puppet-infracloud, glean.. and now with TripleO. So in my opinion, it shall
be an independent project, with core contributors from both sides.

On Thu, Jan 12, 2017 at 8:51 PM, Paul Belanger 
wrote:

> On Thu, Jan 12, 2017 at 02:11:42PM -0500, James Slagle wrote:
> > On Thu, Jan 12, 2017 at 1:55 PM, Emilien Macchi 
> wrote:
> > > On Thu, Jan 12, 2017 at 12:06 PM, Paul Belanger 
> wrote:
> > >> Greetings,
> > >>
> > >> With the containerization[1] of tripleo, I'd like to know more about
> the future of
> > >> diskimage-builder as it relates to the tripleo project.
> > >>
> > >> Reading the recently approved spec for containers, container (image)
> builds are
> > >> no longer under the control of tripleo; by kolla. Where does this
> leave
> > >> diskimage-builder as a project under tripleo?  I specifically ask,
> because I'm
> > >> wanting to start down the path of using diskimage-builder as an
> interface to
> > >> containers.
> > >>
> > >> Basically, is it time to move diskimage-builder out from the tripleo
> project
> > >> into another, or its own? Or is tripleo wanting to more forward on
> development
> > >> efforts on diskimage-builder.
> > >
> > > Looking at stats on who is actively contributing into DIB:
> > > http://stackalytics.com/?module=diskimage-builder
> > >
> > > It seems that we have some folks from infra and some folks on dib
> > > only, and a few contributors from TripleO.
> > >
> > > I guess the best option is to ask DIB contributors: do you want to own
> > > the project you're committing to?
> > > If not, is it something that should stay in TripleO (imo no) or move
> > > into openstack-infra (imo yes, if infra agrees).
> > >
> > > With my PTL hat, I'm really open to this thing and I wouldn't mind to
> > > transfer ownership to another group.
> >
> > I was under the impression it was already it's own project team based on:
> > http://lists.openstack.org/pipermail/openstack-dev/2016-July/099805.html
> >
> > It looks like the change was never made in governance however.
> >
> Yes, it just looks like Greg created new core reviewers, not officially
> breaking
> away from tripleo.
>
> If everybody is on board with moving diskimage-builder outside of tripleo,
> we
> need to decided where it lives. Two options come to mind:
>
> 1) Move diskimage-builder into own (big tent?) project. Setup a new PTL,
> etc.
> 2) Move diskimage-builder into openstack-infra (fungi PTL).
> 3) Keep diskimage-builder under tripleo (EmilienM PTL).
>
> Thoughts?
>
> > The reason I -1'd Paul's TripleO spec and suggested it be proposed to
> > diskimage-builder was due to:
> > http://lists.openstack.org/pipermail/openstack-dev/2016-June/098560.html
> and
> > https://review.openstack.org/#/c/336109/
> >
> > I just want to make sure the right set of reviewers who are driving
> > dib development see the spec proposal.
> >
> > --
> > -- James Slagle
> > --
> >
> > 
> __
> > 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
>
> __
> 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
>



-- 
Yolanda Robla Mota
NFV Partner Engineer
yrobl...@redhat.com
+34 605641639
__
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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Paul Belanger]

On Thu, Jan 12, 2017 at 02:11:42PM -0500, James Slagle wrote:
> On Thu, Jan 12, 2017 at 1:55 PM, Emilien Macchi  wrote:
> > On Thu, Jan 12, 2017 at 12:06 PM, Paul Belanger  
> > wrote:
> >> Greetings,
> >>
> >> With the containerization[1] of tripleo, I'd like to know more about the 
> >> future of
> >> diskimage-builder as it relates to the tripleo project.
> >>
> >> Reading the recently approved spec for containers, container (image) 
> >> builds are
> >> no longer under the control of tripleo; by kolla. Where does this leave
> >> diskimage-builder as a project under tripleo?  I specifically ask, because 
> >> I'm
> >> wanting to start down the path of using diskimage-builder as an interface 
> >> to
> >> containers.
> >>
> >> Basically, is it time to move diskimage-builder out from the tripleo 
> >> project
> >> into another, or its own? Or is tripleo wanting to more forward on 
> >> development
> >> efforts on diskimage-builder.
> >
> > Looking at stats on who is actively contributing into DIB:
> > http://stackalytics.com/?module=diskimage-builder
> >
> > It seems that we have some folks from infra and some folks on dib
> > only, and a few contributors from TripleO.
> >
> > I guess the best option is to ask DIB contributors: do you want to own
> > the project you're committing to?
> > If not, is it something that should stay in TripleO (imo no) or move
> > into openstack-infra (imo yes, if infra agrees).
> >
> > With my PTL hat, I'm really open to this thing and I wouldn't mind to
> > transfer ownership to another group.
> 
> I was under the impression it was already it's own project team based on:
> http://lists.openstack.org/pipermail/openstack-dev/2016-July/099805.html
> 
> It looks like the change was never made in governance however.
> 
Yes, it just looks like Greg created new core reviewers, not officially breaking
away from tripleo.

If everybody is on board with moving diskimage-builder outside of tripleo, we
need to decided where it lives. Two options come to mind:

1) Move diskimage-builder into own (big tent?) project. Setup a new PTL, etc.
2) Move diskimage-builder into openstack-infra (fungi PTL).
3) Keep diskimage-builder under tripleo (EmilienM PTL).

Thoughts?

> The reason I -1'd Paul's TripleO spec and suggested it be proposed to
> diskimage-builder was due to:
> http://lists.openstack.org/pipermail/openstack-dev/2016-June/098560.html and
> https://review.openstack.org/#/c/336109/
> 
> I just want to make sure the right set of reviewers who are driving
> dib development see the spec proposal.
> 
> -- 
> -- James Slagle
> --
> 
> __
> 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

__
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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[James Slagle]

On Thu, Jan 12, 2017 at 1:55 PM, Emilien Macchi  wrote:
> On Thu, Jan 12, 2017 at 12:06 PM, Paul Belanger  wrote:
>> Greetings,
>>
>> With the containerization[1] of tripleo, I'd like to know more about the 
>> future of
>> diskimage-builder as it relates to the tripleo project.
>>
>> Reading the recently approved spec for containers, container (image) builds 
>> are
>> no longer under the control of tripleo; by kolla. Where does this leave
>> diskimage-builder as a project under tripleo?  I specifically ask, because 
>> I'm
>> wanting to start down the path of using diskimage-builder as an interface to
>> containers.
>>
>> Basically, is it time to move diskimage-builder out from the tripleo project
>> into another, or its own? Or is tripleo wanting to more forward on 
>> development
>> efforts on diskimage-builder.
>
> Looking at stats on who is actively contributing into DIB:
> http://stackalytics.com/?module=diskimage-builder
>
> It seems that we have some folks from infra and some folks on dib
> only, and a few contributors from TripleO.
>
> I guess the best option is to ask DIB contributors: do you want to own
> the project you're committing to?
> If not, is it something that should stay in TripleO (imo no) or move
> into openstack-infra (imo yes, if infra agrees).
>
> With my PTL hat, I'm really open to this thing and I wouldn't mind to
> transfer ownership to another group.

I was under the impression it was already it's own project team based on:
http://lists.openstack.org/pipermail/openstack-dev/2016-July/099805.html

It looks like the change was never made in governance however.

The reason I -1'd Paul's TripleO spec and suggested it be proposed to
diskimage-builder was due to:
http://lists.openstack.org/pipermail/openstack-dev/2016-June/098560.html and
https://review.openstack.org/#/c/336109/

I just want to make sure the right set of reviewers who are driving
dib development see the spec proposal.

-- 
-- James Slagle
--

__
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

Re: [openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Emilien Macchi]

On Thu, Jan 12, 2017 at 12:06 PM, Paul Belanger  wrote:
> Greetings,
>
> With the containerization[1] of tripleo, I'd like to know more about the 
> future of
> diskimage-builder as it relates to the tripleo project.
>
> Reading the recently approved spec for containers, container (image) builds 
> are
> no longer under the control of tripleo; by kolla. Where does this leave
> diskimage-builder as a project under tripleo?  I specifically ask, because I'm
> wanting to start down the path of using diskimage-builder as an interface to
> containers.
>
> Basically, is it time to move diskimage-builder out from the tripleo project
> into another, or its own? Or is tripleo wanting to more forward on development
> efforts on diskimage-builder.

Looking at stats on who is actively contributing into DIB:
http://stackalytics.com/?module=diskimage-builder

It seems that we have some folks from infra and some folks on dib
only, and a few contributors from TripleO.

I guess the best option is to ask DIB contributors: do you want to own
the project you're committing to?
If not, is it something that should stay in TripleO (imo no) or move
into openstack-infra (imo yes, if infra agrees).

With my PTL hat, I'm really open to this thing and I wouldn't mind to
transfer ownership to another group.

Thanks,

> [1] 
> https://specs.openstack.org/openstack/tripleo-specs/specs/ocata/containerize-tripleo-overcloud.html
>
> __
> 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

__
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

[openstack-dev] [tripleo][diskimage-builder] Status of diskimage-builder

[Paul Belanger]

Greetings,

With the containerization[1] of tripleo, I'd like to know more about the future 
of
diskimage-builder as it relates to the tripleo project. 

Reading the recently approved spec for containers, container (image) builds are
no longer under the control of tripleo; by kolla. Where does this leave
diskimage-builder as a project under tripleo?  I specifically ask, because I'm
wanting to start down the path of using diskimage-builder as an interface to
containers.

Basically, is it time to move diskimage-builder out from the tripleo project
into another, or its own? Or is tripleo wanting to more forward on development
efforts on diskimage-builder.

[1] 
https://specs.openstack.org/openstack/tripleo-specs/specs/ocata/containerize-tripleo-overcloud.html

__
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