Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-21
20:05:29 mriedem dansmith: if we removed device_name from the bdm object in server create, yeah.
20:05:40 dansmith but I also don't really understand the exchange between you two either
20:05:46 dansmith I think there's ML context probably
20:05:52 mriedem ftersin pointed out some stuff about image-defined BDMs don't have tags
20:06:00 mriedem it's in the spec review
20:06:07 mriedem artom: not sure
20:06:10 mriedem you wrote that code :)
20:06:23 artom mriedem, I have the memory of a goldfish
20:06:41 dansmith oh, image-defined I see.. either way, those device names don't get honored any more than the volume-attach ones, so I don't see what that matters
20:06:54 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: DiskAdapter parent class https://review.openstack.org/549053
20:07:06 artom mriedem, yeah, we do: https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L8570
20:07:13 artom But... where does that device name come from?
20:07:18 mriedem oh i guess there was some ML stuff http://lists.openstack.org/pipermail/openstack-dev/2017-April/114858.html
20:07:57 mriedem artom: i think nova.virt.libvirt.blockinfo.py
20:08:27 artom mriedem, is that the one the user gives in the boot request?
20:08:32 artom Or attach request, whatever
20:08:43 mriedem https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L8703
20:08:47 mriedem no,
20:08:52 mriedem the libvirt driver completely ignores what the user requested
20:08:55 mriedem since liberty
20:09:01 mriedem see ^
20:09:36 mriedem when you attach a volume, the api rpc calls the compute to create the bdm and get the device name from the driver
20:09:44 mriedem assuming the stupid instance isn't shelved offload
20:09:47 dansmith mriedem: yeah, from that thread I'm not sure why tags won't work
20:10:41 dansmith oh, because the image properties
20:10:48 mriedem yeah it's a different use case,
20:10:54 mriedem i think the image has bdms in it,
20:10:57 mriedem the user can override those,
20:11:05 mriedem but the override relies on the device name as the primary key
20:11:11 dansmith but .. if they're providing bdms, they're doing full override, or is it that they're doing override of individual bdms referenced by name?
20:11:22 mriedem so you say, the image has vda/vdb/vdc and i don't like the image-defined vdc bdm, so i'm going to overwrite it
20:11:29 mriedem the latter i think
20:11:30 dansmith yeah, okay
20:11:47 dansmith that seems like a really odd thing that we ever allowed
20:11:58 mriedem heh, that's what i said
20:12:02 mriedem "people do this?!"
20:12:13 openstackgerrit Eric Berglund proposed openstack/nova master: WIP: PowerVM Driver: Localdisk https://review.openstack.org/549300
20:12:19 dansmith like, it seems weird that you would expect to provide bdms, but get a union of the bdms on the image and the ones you provided, with some replacement
20:12:32 dansmith mriedem: so since this is so obscure,
20:13:08 dansmith what if we just defined a pattern like volume-bdm-$devname and auto-tag BDMs from the image, and then you can use the tag on the bdm command line to override those?
20:13:18 dansmith I mean, I know it's kinda secret sauce, but so is what we have today
20:13:20 openstackgerrit Eric Berglund proposed openstack/nova master: WIP: PowerVM Driver: Localdisk https://review.openstack.org/549300
20:13:31 dansmith we could actually document it though going forward
20:13:33 mriedem this is the merge-a-roo https://github.com/openstack/nova/blob/master/nova/compute/api.py#L670
20:13:40 dansmith and avoid the surprise later when we all forget gain
20:14:07 dansmith that that suck-a-roo-s
20:14:10 openstackgerrit Eric Berglund proposed openstack/nova master: WIP: Resize https://review.openstack.org/553583
20:15:03 dansmith the ML thread made it sound like he was amenable to something else if you provided it
20:15:22 openstackgerrit Eric Berglund proposed openstack/nova master: WIP: Resize https://review.openstack.org/553583
20:15:46 dansmith presumably the client (ec2api in this case) could also just get the properties from the image, and generate a fresh new set of BDMs that are the union of the two, if we convert over to not merging in some microversion
20:17:20 mriedem yeah they'd have to do the full override client side
20:17:32 dansmith yeah, and what's wrong with that?
20:17:49 dansmith it'd suck for someone using novaclient, but not so much for ec2api using REST
20:18:30 dansmith what does horizon do if you have an image with BDMs in it? does it properly show what your instance is going to look like pre-boot?
20:19:54 mriedem not sure, don't have a devstack handy
20:20:04 mriedem oh, but, i have a vexxhost handy :)
20:20:38 mriedem also, if we stopped doing the merging in a new microversion that drops device name, the client has two options: use an older microversion for the server create request and hope they didn't need a newer microversion, or merge client side
20:21:18 mriedem nvm i don't know if vexxhost has any images with BDMs in them
20:21:34 dansmith mriedem: did you look or find any documentation that advertises this as a thing?
20:22:13 mriedem https://docs.openstack.org/nova/pike/user/block-device-mapping.html#intermezzo-problem-with-device-names
20:22:20 mriedem "Currently (mid Liberty) users are discouraged from specifying device names for all calls requiring or allowing block device mapping, except when trying to override the image block device mapping on instance boot, and it will likely remain like that in the future. "
20:24:07 dansmith hrm
20:24:33 mriedem that's about all i can find
20:24:50 mriedem from that ML thread: http://lists.openstack.org/pipermail/openstack-dev/2017-April/114866.html
20:24:59 mriedem ess important for pure OpenStack users."
20:24:59 mriedem this is also timely: "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
20:25:25 mriedem i.e. bfv in openstack sucks ux-wise
20:26:42 dansmith yeah
20:26:52 mriedem from what i can tell, we don't even have any direct tests for _merge_bdms_lists
20:26:59 dansmith mriedem: well, I commented and summarized my feelings
20:27:03 dansmith mriedem: heh, nice
20:27:06 dansmith and no tempest test,
20:27:23 dansmith which means it's not part of the are-you-openstack test right?
20:31:19 mriedem interop, no
20:31:26 mriedem most things aren't in interop though fwiw
20:31:36 dansmith I know, I'm just poking
20:32:44 mriedem alright i'll give myself a todo to re-spec-ify this
20:47:18 openstackgerrit Julia Kreger proposed openstack/nova master: WIP: Add microversion to ironic client wrapper call https://review.openstack.org/554762
20:49:27 melwitt ran into something unexpected today, apparently when you specify a non-existent field when creating a nova object, it doesn't complain about it upon create(), it just silently never applies it https://github.com/openstack/nova/blob/master/nova/tests/functional/compute/test_instance_list.py#L69
20:58:32 cfriesen when we evacuate a boot-from-volume instance and it's starting up on the new compute node, would we expect the HTTP API calls to cinder to have the same "req-*" number as the evacuate in nova?
21:04:58 dansmith melwitt: yeah, it's always been that non-field properties are free-form
21:05:21 dansmith that's how we manage local caching of stuff, and some of the other things instance does, for example
21:05:43 dansmith I found it surprising the first time someone else brought it up and was surprised by it :)
21:05:55 melwitt yeah, I guess I haven't used the non-field properties too much. or I keep forgetting about them
21:06:23 sean-k-mooney[m] melwitt: ya that has come up a few times
21:07:48 sean-k-mooney[m] Eveyone finds it surprising as they expect ovo/nova objects to prevent python being python and allowing you to add attributes to objects when ever you feel like it
21:09:10 melwitt I think it was the use of it in the init that threw me off. InstanceMapping(user_id=<id>) looked so official
21:10:33 sean-k-mooney[m] Hum it could still be a bug. Non fields are not serialised, the user id sounds like it should be persistent
21:11:24 melwitt yeah, I'm guessing the use wasn't intentional (it's just in a test)
21:11:38 melwitt I'm trying to recreate a bug and been poking around these functional tests
21:13:23 sean-k-mooney[m] Thats always an interesting experience, your never sure what you will find
21:13:44 openstackgerrit melanie witt proposed openstack/nova stable/pike: DNM: reproducing bug 1746509 https://review.openstack.org/555058
21:13:46 openstack bug 1722404 in OpenStack Compute (nova) ocata "duplicate for #1746509 Database transactions can fail with "TypeError: Can't upgrade a READER transaction to a WRITER mid-transaction" because of scatter_gather_cells" [Undecided,In progress] https://launchpad.net/bugs/1722404 - Assigned to Matt Riedemann (mriedem)
21:18:47 dansmith melwitt: ah, I'd be fine restricting init to only things in fields, that makes plenty of sense to me
21:19:04 dansmith melwitt: just not instance.does_not_exist = True
21:19:44 mriedem ^ is definitely something that tripped me up with something in the nova-network API code that relies on setting things on an object which aren't in fields, and reads that attribute in the REST API
21:19:57 mriedem can't remember which one specifically, but it was probably me that surprised dan about being surprised
21:20:07 dansmith heh
21:20:51 mriedem unrelated, but coincidental to the service / compute node delete and host discovery stuff lately https://bugs.launchpad.net/nova/+bug/1757207
21:20:52 openstack Launchpad bug 1757207 in OpenStack Compute (nova) "compute resource providers not equal to compute nodes in deployment" [Undecided,Incomplete]

Earlier   Later