Open Stack

On 4/2/2017 8:08 PM, Feodor Tersin wrote:
>> Can you give some more details? How does this actually "merge" or
>
>> replace BDMs defined in the image metadata? Is this because we use
>> device name as part of a hack for a primary key in the database [1]? I
>> assume it is. The lack of unique constraint in the BDM data model has
>> also always been a source of bugs, especially with cells v1 and why we
>> talk about adding a uuid column to that table every few months.
>
> Right. This is not pure merging, but replacing, based on device names as
> a primary key. Important point is that it is a user defined, human
> readable key.
>
>> I've never actually heard of this use case but it looks like it's been
>> baked in since the legacy BDM behavior in the code, which is itself a
>> bunch of technical debt that I'd love to remove at some point.
>
> A couple of years ago when Dipanov accidentally broke the merging, we
> asked him to fix it here in ML, and he did it. If it's important, i'll
> find these reviews and ML thread.

The history isn't as important to me. What's frustrating is this is 
something people care about, and has been regressed before, and we don't 
have good enough test coverage or documentation to know it's something 
people do care about. I think before we move forward with any of this, 
we'll want a test added to Tempest that validates this use case so we 
avoid regressing it again.

>
>> I guess what I'm trying to get at is, is this just important for EC2
>> compatibility? Or do non-AWS OpenStack users care about this use case,
>> because we definitely don't advertise this anywhere in our
>> documentation, or test it in any of our integrated testing (Tempest). So
>> just because it happens to work by chance of a poor data model doesn't
>> make me want to bend over backward to keep this working.
>
> Well, i cannot estimate the importance in absolute measurement, but in
> comparison with OpenStack this use case is more important in AWS. Volume
> backed images (EBS images) are used in AWS much more widely than in
> OpenStack. There are some difficulties in Nova and Cinder because that
> users try to avoid using volume backed images in favor of disk based
> (instance-store) ones. This  explain why this use case is less important
> for pure OpenStack users.
>
>> If we wanted to support updating/overriding a specific image BDM during
>> server create, I'd think we could do something more straight-forward in
>> the compute API, like add an "image_bdm_override=True" field to
>> block_device_mapping_v2, something like that. What do you think about
>> that alternative?
>
> Since you want to delete the only natural key from bdm, how to refer on
> a certain bdm in parameters? Honestly, without real merging implemented
> in Nova, such workarounds fused into bdm structure do not look good for
> me. It looks like a crutch for something unfinished. Another
> disadvantages is that this new field may be added into DB, etc., because
> all other bdm fields are. Perhaps more appropriate way is to add a new
> 'ignore_image_bdms' parameter to  run instance method. This brings
> another questions, but does not directly affect bdms at least.

I'm not sure what the best design is for maintaining this in the API 
without using the device name. I rattled off a few options in the spec 
review, but they aren't great options, and some simply won't work for 
older BDM or image resources, so are non-starters. I'm hoping some 
others with a fresh perspective on this can chime in with ideas, 
otherwise I'll bring it up in the nova API subteam meeting this week so 
we can talk about the best way forward.

Thanks again Feodor.

-- 

Thanks,

Matt