[openstack-dev] [TripleO] [diskimage-builder] Howto refactor?

Gregory Haynes greg at greghaynes.net
Wed Jun 1 16:54:47 UTC 2016

On Wed, Jun 1, 2016, at 01:06 AM, Ian Wienand wrote:
> On 06/01/2016 02:10 PM, Andre Florath wrote:
> > My long term goal is, to add some functionality to the DIB's block
> > device layer, like to be able to use multiple partitions, logical
> > volumes and mount points.
> Some thoughts...
> There's great specific info in the readme's of the changes you posted
> ... but I'm missing a single big picture context of what you want to
> build on-top of all this and how the bits fit into it.  We don't have
> a formalised spec or blueprint process, but something that someone who
> knows *nothing* about this can read and follow through will help; I'd
> suggest an etherpad, but anything really.  At this point, you are
> probably the world-expert on dib's block device layer, you just need
> to bring the rest of us along :)

++, but one clarification: We do have a spec process which is to use the
tripleo-specs repo. Since this is obviously not super clear and there is
a SnR issue for folks who are only dib core maybe we should move specs
in to the dib repo?

I also agree that some type of overview is extremely useful. I hesitate
to recommend writing specs because of how much extra work it tends to be
for all of us, but I honestly think that a couple of these features
could individually use specs - more detail in review comments on

> There seems to be a few bits that are useful outside the refactor.
> Formalising python elements, extra cleanup phases, dib-run-parts
> fixes, etc.  Splitting these out, we can get them in quicker and it
> reduces the cognitive load for the rest.  I'd start there.

Splitting these out would help a lot. This whole set of features is
going to take a while to iterate on (sorry! - reviewer capacity is
limited and there are big changes here) and a few of these are pretty
straightforward things I think we really want (such as the cleanup
phase). There's also a lot of risk to us in merging large changes since
we are the poster child for how having external dependencies makes
testing hard. Making smaller changes lets us release / debug /
potentially revert them individually which is a huge win.

> #openstack-infra is probably fine to discuss this too, as other dib
>   knowledgeable people hang out there.
> -i

As for what to do about the existing and potentially conflicting changes
-  that's harder to answer. I think there's a very valid concern from
the original authors about scope creep of their original goal. We also,
obviously, don't want to land something that will make it more difficult
for us to enhance later on.

I think with the LVM patch there actually isn't much of risk to making
your work more difficult - the proposed change is pretty small and has a
small input surface area - it should be easy to preserve its behavior
while also supporting a more general solution. For the EFI change there
are some issues you've hit on that need to be fixed, but I am not sure
they are going to require basing the change off  a more general fix. It
might be as easy as copying the element contents in to a new dir when a
more general solution is completed in which case getting the changes
completed in smaller portions is more beneficial IMO.

I also wanted to say thanks a ton for the work and reviews - it is
extremely useful stuff and we desperately need the help. :)


More information about the OpenStack-dev mailing list