| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-13 | |||
| 17:58:45 | mriedem | but we destroy the guest vm from the compute host | |
| 17:58:51 | mriedem | keep ports and volumes attached in dbs | |
| 17:59:02 | mriedem | when we destroy the guest, we disconnect any volumes | |
| 17:59:16 | mriedem | then the instance is in this shelve-offloaded state, where it doesn't have a host | |
| 17:59:24 | mriedem | (we also take a snapshot of it before offloading it) | |
| 17:59:27 | hemna | ok | |
| 17:59:33 | hemna | so it's like a dormant vm | |
| 17:59:36 | mriedem | when you unshelve the instance, we take the snapshot image and boot the server on a new host | |
| 17:59:43 | mriedem | sort of yeah | |
| 17:59:50 | mriedem | it might land on the same host as before, but it might not | |
| 18:00:25 | hemna | yah, so I believe terminate_connection should be called then in this case, to ensure that the backend disconnects from the host | |
| 18:00:35 | dane-fichter | jaypipes: also I can answer most cert validation questions while peter-hamilton is afk | |
| 18:00:35 | mriedem | when the instance is created on a new host, we call initialize_connection again | |
| 18:00:43 | hemna | makes sense | |
| 18:00:51 | openstackgerrit | Mathieu Gagné proposed openstack/nova-specs master: Nova support for attached volume extend https://review.openstack.org/453272 | |
| 18:01:58 | mriedem | hemna: the funny thing is on unshelve, | |
| 18:02:00 | jgriffith | mriedem hemna there is no terminate_connection, only “attachment_delete” or “update" | |
| 18:02:02 | jgriffith | :) | |
| 18:02:07 | hemna | :P | |
| 18:02:09 | mriedem | is i don't think we ever call connect_volume in brick on the new host | |
| 18:02:19 | hemna | ! | |
| 18:02:22 | mriedem | so even though we initialize the connection, we don't connect the volume | |
| 18:02:26 | mriedem | as far as i can tell | |
| 18:02:28 | hemna | oops | |
| 18:02:48 | mriedem | let me check the driver.spawn() method though | |
| 18:02:51 | mriedem | maybe it's done there | |
| 18:02:54 | mriedem | some of this garbage is hidden | |
| 18:03:09 | hemna | well if the volume is showing up there, then it has to get called at some point | |
| 18:03:21 | mriedem | i don't know if it does, this is all via code inspection, | |
| 18:03:26 | mriedem | i don't have a devstack handy to recreate | |
| 18:04:18 | mriedem | yeah i don't see brick called during spawn during unshelve | |
| 18:08:52 | openstack | Launchpad bug 1547142 in OpenStack Compute (nova) "A shelved_offload VM's volumes are still attached to a host" [Medium,Confirmed] | |
| 18:08:52 | mriedem | ha https://bugs.launchpad.net/nova/+bug/1547142 | |
| 18:09:30 | mriedem | the fix on the nova side for this was blocked by some changes on the cinder side | |
| 18:09:31 | mriedem | of course | |
| 18:10:35 | openstackgerrit | Dan Smith proposed openstack/nova master: Fix hypervisors api missing HostMappingNotFound handlers https://review.openstack.org/456227 | |
| 18:10:40 | hemna | oh missing the remove_export | |
| 18:12:21 | hemna | terminate_connection will do it for most of the cinder backends | |
| 18:12:21 | hemna | well It's backend dependent really | |
| 18:14:49 | hemna | lvm of course uses remove_export to do the real work, and does nothing in terminate_connection | |
| 18:14:56 | mriedem | hemna: that's what the guy on the bug originally asked, can't we at least call terminate connection | |
| 18:15:06 | mriedem | does terminate_connection call remove_export? | |
| 18:15:07 | hemna | you can | |
| 18:15:17 | hemna | but in the case of lvm tgt, terminate_connection does nothing | |
| 18:15:19 | hemna | nope | |
| 18:15:29 | hemna | the volume manager calls both of those | |
| 18:15:41 | mriedem | so what calls remove_export for lvm tgt? detach? | |
| 18:16:21 | hemna | volume manager's remove_export does | |
| 18:16:28 | hemna | and some other edge cases | |
| 18:16:42 | mriedem | yeah but what calls that from the api entry point? | |
| 18:16:48 | hemna | looking | |
| 18:16:50 | mriedem | detach? delete volume? | |
| 18:16:51 | mriedem | ok | |
| 18:17:33 | hemna | I don't see anything in the api that calls it..... | |
| 18:19:45 | mriedem | btw, i looked up shelved + volumes in nova bugs, | |
| 18:19:49 | mriedem | what a treasure trove of broken | |
| 18:19:57 | hemna | detach_volume calls it | |
| 18:20:06 | mriedem | hemna: ah ok, | |
| 18:20:13 | mriedem | and we don't call detach during shelve offload | |
| 18:20:20 | mriedem | because we want the volume to logically stay attached to the instance | |
| 18:20:25 | hemna | well detach_volume calls the driver's remove_export at least | |
| 18:21:19 | hemna | jgriffith, does the new API account for being able to unexport the volume w/o marking it as unattached ? | |
| 18:21:41 | hemna | or we'll have to add a new Cinder API entry point for remove export | |
| 18:22:13 | hemna | or...does it make sense that terminate_connection in the volume manager would automatically call remove_export too | |
| 18:22:17 | hemna | ... | |
| 18:23:13 | openstackgerrit | Daniel Pawlik proposed openstack/nova master: Changed network_info variable in test_create_configdrive https://review.openstack.org/436953 | |
| 18:23:19 | hemna | honestly I never understood why there was terminate_connection vs remove_export, and not just a single merged capability | |
| 18:23:21 | openstack | Launchpad bug 1554440 in OpenStack Compute (nova) "Show volume attachment exception does not looks good if server is in shelved_offloaded state" [Medium,Confirmed] | |
| 18:23:21 | mriedem | gmann: i just found https://bugs.launchpad.net/nova/+bug/1554440 and i don't agree that it requires a microversion to fix a regression introduced with 2.20 | |
| 18:23:27 | mriedem | hemna: yeah that would be nicer | |
| 18:23:47 | mriedem | oomichi: jaypipes: why do you think we need a microversion bump to fix this bug? https://review.openstack.org/#/c/290196/ | |
| 18:23:53 | mriedem | oomichi: jaypipes: it's clearly a regression in 2.20 | |
| 18:31:58 | jangutter | Is it to late to get "Netronome SmartNIC Enablement" spec https://review.openstack.org/#/c/456386/ approved before Pike? | |
| 18:33:15 | artom | jangutter, spec freeze is today, so I think it's unlikely for Pike, yes | |
| 18:33:41 | artom | Unless you whip the spec cores into a flurry of activity ;) | |
| 18:34:38 | mriedem | sean-k-mooney: can you take a look at that netronome smartnic spec? ^ | |
| 18:34:42 | mriedem | sean-k-mooney: that seems right up your alley | |
| 18:35:14 | sean-k-mooney | mriedem: sure i think i was already reviewing some os-vif changes related to this | |
| 18:37:16 | jangutter | Unfortunately it took much, much longer than expected to get the internal clearance for this. I believe Mellanox would also like to get something similar merged, but their dev is OOO at the moment. | |
| 18:37:34 | mriedem | jangutter: fwiw, this is a very nicely written spec | |
| 18:37:37 | mriedem | so congratulations on that | |
| 18:38:19 | jangutter | Hey, I can't take credit for that, my barbarian gibberish was transformed into flowery language by our internal review. | |
| 18:38:42 | artom | "barbarian gibberish" :D | |
| 18:38:48 | artom | I shall endeavour to use that somewhere | |
| 18:39:44 | mriedem | +2 | |
| 18:39:58 | mriedem | jaypipes: you're probably good for https://review.openstack.org/#/c/456386/ - it's pretty straight forward vendor vif type stuff | |
| 18:40:25 | mriedem | jangutter: well i commend your internal team for getting their ducks in a row then | |
| 18:41:00 | jangutter | It's my first time using gerrit... The scary thing is that I feel nearly the same way about it as I felt about first encountering "git". | |
| 18:41:14 | jangutter | "where has this been all my life". | |
| 18:41:18 | mriedem | heh | |
| 18:42:01 | artom | Do we need a new API version for that kind of possible parameter value change? | |
| 18:43:04 | mriedem | artom: api parameter value change where? | |
| 18:43:19 | mriedem | that's all on the neutron side isn't it? | |
| 18:43:38 | artom | https://review.openstack.org/#/c/456386/5/specs/pike/approved/netronome-smartnic-enablement.rst@134 | |
| 18:43:45 | artom | I may be reading it completely wrong | |
| 18:44:10 | jangutter | Well, there's one new "VNIC" type we're proposing. | |
| 18:44:19 | mriedem | artom: there are no rest api changes to the compute api | |
| 18:44:26 | mriedem | i would have just left that section as None to avoid confusion | |
| 18:44:36 | mriedem | artom: but otherwise i think of this like https://github.com/openstack/nova/commit/32069c8f397e395134c3b1142c2d852640685fef | |
| 18:44:44 | artom | mriedem, ah, right, you pass that to Neutron when you create the port | |