[openstack-dev] incubating diskimage-builder?

Robert Collins robertc at robertcollins.net
Sun May 26 07:24:50 UTC 2013


On 26 May 2013 19:11, Mark Washenberger <mark.washenberger at markwash.net> wrote:

>>  I'd be delighted to collaborate with any of the PTL's in OpenStack
>> today - but fFor all that it's small, it has it's own unique
>> challenges in keeping it flexible, fast and safe, so I feel hesitant
>> about simply handing guidance of it over to PTL control in the context
>> of a project which is API focused : this is low level OS plumbing
>> which it's own problem domain.
>
>
> Ahem. . . I'm guessing you're talking about Glance here?
> No worries, though. I think we can all agree there is a huge difference
> between an API that publishes images and a tool for building images.

There have been many discussions about where to bind
Diskimage-builder; glance; nova; standalone project (within
OpenStack), standalone project (outside of OpenStack). So no - I'm not
concerned about any specific PTL - If I had such concerns, I would
voice them. The concern is that the problem domains are really very
different.

> My question is, are you trying to begin handing off diskimage-builder?

Not at all; it's a core part of TripleO and we've probably got 2-3
years of evolution before we can call TripleO done. Until then such
questions are moot ;).

> Or
> are you just figuring that joining another project would necessarily mean
> you have to lose a certain level of control? Just trying to get a sense of
> your motivations and how they inform your (very much appreciated) concerns.

It's mainly a fear of being in the position of being told 'do X' for
di-b, when it's not actually the technically right thing for di-b. I
appreciate that if Di-b becomes a formal OpenStack project in it's own
right, that PTL for it becomes up for vote etc; but equally I have
confidence in the voting process to identify folk that are fully up to
speed in the problems and challenges around a given project.

> FWIW, if diskimage-builder joined Glance during my tenure, I'd think it best
> for me to be pretty hands off--in part because you clearly know what you're
> doing with the project--in part because I clearly would not know what I was
> doing with it :-).
>
> But that's not to say that a future Glance PTL wouldn't be well positioned
> to appreciate and manage the different focuses of each project. I'm very
> eager to hear other folk's opinions. In an ideal world, would these two
> projects have a strong reason to share technical leadership?

To consider that, lets talk about a slightly bigger scope first.

There are, AFAICT, 4 closely related things that would be great to have.

* Run Operating System installers and capture images. [e.g. Oz]
* Prepare Golden Images by transforming disk/partition images and
installing software / drivers etc.
  * For Unix style OSs'  [e.g. diskimage-builder]
  * For Windows [sadly, it's really very different]
* An API to access all of this functionality.

The last of these looks like a Glance problem to me : while it's not
in Glance's existing scope, it doesn't seem different enough to
warrant a new API project. What do you think?

So I'd say - if the other three were to be something driven by Glance,
that's a pretty strong reason for them to be working very closely with
Glance. I don't know if that implies same-leadership or not.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services



More information about the OpenStack-dev mailing list