Open Stack

On 4/2/2017 10:10 PM, Matt Riedemann wrote:
> 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.
>

mdbooth raised a good point in the spec about the device just being a 
convenient tag essentially for correlating the values for the image bdm 
override during server create. I was thinking, since we have tags for 
BDMs now as of the 2.32 microversion, couldn't we rely on those for the 
image bdm override at some point?

Granted, we need to do two other things first:

1. Allow tagging BDMs during volume attach (Artom has a series for that 
in Pike already).

2. Expose BDM tags out of the REST API (I have a spec for this but it's 
getting caught up in also exposing VIF tags, which depends on what we 
decide to do with os-virtual-interfaces and the os-interface APIs).

--

I raised the question though, could we move forward with removing the 
device field from the "POST /servers/{server_id}/os-volume_attachments" 
API since that doesn't do anything with image BDM overrides.

-- 

Thanks,

Matt