[openstack-dev] [TripleO] [diskimage-builder] Howto refactor?
andre at florath.net
Thu Jun 2 06:37:05 UTC 2016
> ++, 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?
Good to know!
I'd really love to use the dib repo for this: IMHO the spec, requirements,
design and source code should go together.
> 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.
Of course I tried smaller parts; but for some changes the source code
other parts must be changed which again needs changes.
Is like sticky spaghetti: you start with a single noodle polling out
but when you finished you have the whole pot.
Will have a detailed look again.
> 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.
A general remark here: I do not want to block features.
I just try to give my opinion - which might be wrong.
If you think, the patches are fine: let them go.
> 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.
If you are really talking about 'preserving the behavior' and not
'preserving the user experience' (like how to use and configure LVM)
I'm on your side.
I'm somewhat careful with this patch:
For me the use case (the WHY behind) is still completely unclear -
and questions about this are not answered .
The only small hint (building docker images) make completely no sense
to me: docker files are (more or less) tar files; LVM just cannot
be used. 
I'm missing the 'Big Picture' here ;-)
> 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.
My opinion here is that this patch adds to the stickiness of the
It adds more places where assumptions are made about names of block device
or partition names. Of course it's possible to clean up afterwards -
maybe this is a strange attitude of me - I try to clean up things
before doing the work.
One more technical detail here: the partitions are currently organized
in the way, that the boot partition is the second one. Did you ever
saw a system like this?
I asked me, why this was done in this way and came to the conclusion:
because other parts of the source code assume, that the first
partition is the root partition.
So you get a running EFI system, but it is not longer possible to
enlarge the root partition...
But again: these are only my opinions - it's you who decide.
> I also wanted to say thanks a ton for the work and reviews - it is
> extremely useful stuff and we desperately need the help. :)
Thank you all for your support and explanations!
I have not that much time - because I do everything in my spare time here.
Unfortunately looks like I need to spend more time writing mails and
documentation instead of source code :-)
More information about the OpenStack-dev