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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
