| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-21 | |||
| 20:00:47 | mriedem | sriov ports are attached the same way | |
| 20:00:55 | mriedem | they have to be pre-created in neutron is all with the special binding profile i think | |
| 20:01:10 | dansmith | I thought there was some way to attach something where we were still missing tag function | |
| 20:01:12 | mriedem | or are you referring to the bug that artom was trying to fix | |
| 20:01:36 | mriedem | https://review.openstack.org/#/c/533805/ ? | |
| 20:01:45 | dansmith | anyway, yes, I think making those three changes together makes sense. I need to refresh on the bfv/ec2 issue I guess, | |
| 20:01:54 | dansmith | because that doesn't sound like a great reason to remove it from bfv either but.. | |
| 20:02:01 | dansmith | to nop | |
| 20:02:03 | dansmith | not | |
| 20:02:22 | mriedem | yeah, i said the same to ftersin basically, it is completely undocumented and untested behavior | |
| 20:03:05 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI volume driver https://review.openstack.org/526094 | |
| 20:04:16 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: Snapshot https://review.openstack.org/543023 | |
| 20:04:22 | artom | mriedem, I thought we matches volume tags based on device name? | |
| 20:04:31 | artom | *matched | |
| 20:05:04 | dansmith | mriedem: if we remove it, it prevents them from using the boot call past that microversion forever I guess? | |
| 20:05:27 | dansmith | mriedem: I guess I don't see why a tag on bfv won't work the same for them, | |
| 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 | 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:24:59 | mriedem | ess important for pure OpenStack users." | |
| 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 | |