Open Stack

> 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.

> 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.

Thanks,
Feodor Tersin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170403/402413f5/attachment.html>