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 https://review.openstack.org/#/c/319591/5. > > 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. :) Cheers, Greg __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
