Earlier  
Posted Nick Remark
#openstack-nova - 2018-03-21
19:20:06 mriedem in https://review.openstack.org/#/c/549789/ we are getting both jobs b/c at this point the legacy job is still in openstack-zuul-jobs
19:20:14 mriedem yeah i have all of thoes patches lined up
19:20:17 mriedem https://review.openstack.org/#/q/topic:bp/remove-nova-network+(status:open+OR+status:merged)
19:24:25 dansmith mriedem: cool, +2 on the bottom two
19:24:37 dansmith melwitt: ^
19:44:00 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Preserve multiattach flag when refreshing connection_info https://review.openstack.org/555029
19:44:13 openstackgerrit Matt Riedemann proposed openstack/os-vif stable/pike: ovs: do not delete port if already exists https://review.openstack.org/550080
19:53:56 mriedem to do that from.
19:53:56 mriedem dansmith: i skimmed the review comments on https://review.openstack.org/#/c/452546/ again and there were some todos that came out of that as prereqs, one of which was tagged attach which we've had since pike. there was another about returning bdm tags out of the volume attachments API. i had a separate spec for that which got held up in committee because of local disk tags and also exposing vifs tags in GET requests but which
19:54:30 mriedem one thing that could move it forward was just remove device_name from the volume attach API (not bfv), because that doesn't have the sneaky ec2 thing that ftersin was -1ing this for
19:55:35 dansmith mriedem: ah, that seems like incremental improvement and probably the 90% case where people attach a volume and expect it to go in a certain place
19:57:05 mriedem the device name is also presumably for correlating on the guest right?
19:57:26 mriedem i know this volume has something in it that my app needs, so i'll attach it at vdc and my guest will expect it to be at vdc
19:57:34 dansmith yeah
19:57:40 dansmith it's the only use for it
19:59:18 mriedem so i think what i'd propose, if i were to redo this, is (1) drop device_name from attach volume API, (2) return tags in GET calls to the os-volume_attachments and os-interface APIs
19:59:53 mriedem and then cross my fingers that john, booth, feodor and artom don't show up to review the spec
19:59:58 dansmith and take tags in volume/interface attach?
20:00:02 dansmith or do we already have that?
20:00:07 mriedem we've had that since pike
20:00:13 mriedem that was one of the pre-reqs for this other removal spec
20:00:24 dansmith on both interface and volume? but not sriov or something?
20:00:29 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: Network interface attach/detach https://review.openstack.org/546813
20:00:34 mriedem same
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

Earlier   Later