| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-13 | |||
| 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 | |
| 18:45:00 | mriedem | yeah, how neutron handles that i don't know | |
| 18:45:14 | jangutter | Yeah, and that changes to text basically. | |
| 18:45:41 | jangutter | And Neutron has a matching bit of text to pick up the same type of VNIC. | |
| 18:46:23 | jangutter | So, technically, the protocol changes by "new allowed value combinations". Where previously those would error out. | |
| 18:47:22 | jangutter | Meaning an opportunity for extra error handling and nicer exceptions, of course. | |
| 18:48:14 | artom | jangutter, right, but those new allowed value combinations aren't in the Nova REST API, right? | |
| 18:48:16 | jangutter | Oh hang on, I'm confused, Neutron tells Nova, it's the other way around. Blame a week of late nights. | |
| 18:48:34 | mriedem | right, | |
| 18:48:38 | mriedem | you create the port in neutron, | |
| 18:48:40 | artom | User tells Neutron, Neutron tells Nova is what I think the workflow is | |
| 18:48:51 | mriedem | nova gets the vif type from the port and determines how to plug it on the host using os-vif | |
| 18:49:07 | jangutter | OK, so newbie question, where's the REST API defined.... | |
| 18:49:45 | artom | jangutter, defined? All over the place ;) Documented? https://developer.openstack.org/api-ref/compute/ for Nova | |
| 18:50:06 | artom | https://developer.openstack.org/api-ref/networking/ for Neutron | |
| 18:50:27 | jangutter | Hence "APIImpact" | |
| 18:50:54 | artom | Right, except I don't think your spec actually has one | |
| 18:51:51 | jangutter | :-O | |
| 18:53:08 | artom | jangutter, you'd be changing the vnic-type here: https://developer.openstack.org/api-ref/networking/v2/index.html?expanded=create-port-detail, right? | |
| 18:54:00 | jangutter | artom: yeah, binding:vnic_type, port binding extended attribute. | |
| 18:54:23 | artom | So that's the Neutron REST API - Nova just consumes that | |
| 18:55:24 | jangutter | Aaah, so that's where the core API impact rests. | |
| 18:55:46 | artom | Yeah, I think that's where you'd add your type | |