| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-13 | |||
| 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 | |
| 18:57:20 | jangutter | OK, so that means we'd need to submit a Neutron API spec change too? | |
| 18:57:46 | mriedem | jangutter: neutron uses launchpad bugs tagged as RFEs | |
| 18:57:48 | mriedem | for smaller things | |
| 18:57:53 | mriedem | i don't think they require a spec for everything | |
| 18:58:02 | mriedem | but i'm not totally familiar with their process | |
| 18:58:15 | mriedem | jangutter: https://docs.openstack.org/developer/neutron/policies/blueprints.html | |
| 18:59:48 | jangutter | mriedem: OK. Should I add that task to the spec or the blueprint? | |
| 19:00:14 | mriedem | jangutter: not the nova one no | |
| 19:00:35 | mriedem | well, you could just call out a dependency on needing to get that support into neutron, but it's kind of implied | |
| 19:01:16 | jangutter | OK. It's a bit of a chicken/egg situation. Both sides need the support at roughly the same time. | |
| 19:01:31 | artom | jangutter, also, and I'm only superficially familiar with this sort of thing, but do you need a new vnic *and* vif type? | |
| 19:02:26 | jangutter | I think sean-k-mooney pointed out that we don't, just new portbinding types. | |
| 19:03:36 | jangutter | It would mean the OVS vif type is now one of the most overloaded ones in the universe. | |
| 19:06:39 | vladikr | what are the chances for anyone looking at the spice spec again? https://review.openstack.org/#/c/442040 ? | |
| 19:07:21 | artom | Heh, while we're doing last-minute spec merged ;) mriedem ^^ | |
| 19:07:26 | artom | *merges | |
| 19:07:56 | artom | To be completely honest, I feel like we should have bugged alex_xu for the API part earlier | |
| 19:08:25 | vladikr | the spec was there for a long while - definitely not a last minute spec | |