| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-11 | |||
| 14:54:19 | jaypipes | sdague: well, the user could easily poll on GET /ports/{port_id} for the attachment state. | |
| 14:54:39 | sdague | jaypipes: yeh, that's probably reasonable | |
| 14:54:43 | mriedem | sdague: i think ^ is what tempest does | |
| 14:54:52 | mriedem | i added the code to do it i think, will look | |
| 14:54:57 | sdague | so it only shows up in servers once it's really there | |
| 14:55:02 | mriedem | mordred: we already do that | |
| 14:55:06 | sdague | mordred: you can add ports later too | |
| 14:55:09 | mriedem | we wait for the vif plug callback from neutron | |
| 14:55:28 | jaypipes | mordred: we're talking about the live attach/detach of a port. | |
| 14:55:34 | mordred | sdague: yes - post-create port attach I think polling the port in neutron for attach state is right - or port not showing up on server until it's attache | |
| 14:55:36 | mordred | either way | |
| 14:56:03 | mriedem | sdague: https://github.com/openstack/tempest/blob/master/tempest/api/compute/servers/test_attach_interfaces.py#L100 | |
| 14:56:21 | mriedem | sdague: https://github.com/openstack/tempest/blob/master/tempest/common/waiters.py#L264 | |
| 14:56:39 | mriedem | so tempest totally relies on the port_state in the os-interface response to see when the port is ACTIVE | |
| 14:56:42 | mriedem | and the attach is done | |
| 14:57:00 | sdague | mriedem: ok, sure | |
| 14:57:09 | sdague | so, you down at the bottom of the etherpad | |
| 14:57:28 | sdague | I think we could get that whole thing with the ports sub resource that jay proposed | |
| 14:57:52 | mordred | mriedem: maybe it's time to switch tempest to poll neutron port state instead? | |
| 14:58:29 | mriedem | mordred: i'm not saying that can't be change | |
| 14:58:38 | mriedem | the test doesn't even run if you're using nova-net https://github.com/openstack/tempest/blob/master/tempest/api/compute/servers/test_attach_interfaces.py#L35 | |
| 14:59:04 | mordred | mriedem: awesome. so it's only a neutron test anyway :) | |
| 14:59:09 | sdague | mriedem: sure, but also realize this isn't contract code, it's the incidental code | |
| 14:59:19 | mriedem | mordred: os-interface GET ONLY works for neutron | |
| 14:59:24 | mriedem | it's a NotImplementedError for nova-net | |
| 14:59:28 | sdague | yeh | |
| 14:59:35 | mriedem | and os-virtual-interfaces ONLY works for nova-net, and is a NotImplementedError for neutron | |
| 14:59:37 | mordred | mriedem: I don't know that I even knew os-interface existed | |
| 14:59:40 | mriedem | hence me wanting to collapse these | |
| 15:00:09 | sdague | mriedem: anyway, on your level of rage, what about the add ports to server document, provide this new minimalist interface for the port attach/detach/attaching status | |
| 15:00:15 | jaypipes | mriedem, sdague: sounds like we are converging on something here.. | |
| 15:00:39 | johnthetubaguy | I always wish the volume attachments and network attachments kinda look/feel similar in the API, not sure I like either right now though | |
| 15:00:47 | mordred | as I say that ... | |
| 15:00:57 | mriedem | johnthetubaguy: i was trying to get them closer, this gets them much further apart | |
| 15:00:58 | mordred | https://developer.openstack.org/api-ref/compute/?expanded=list-port-interfaces-detail is pretty | |
| 15:01:44 | mriedem | sdague: honestly it's a lot more than i was planning to do for this | |
| 15:01:44 | sdague | mordred: you just said that did you no good :P | |
| 15:01:51 | johnthetubaguy | mriedem: would we likely take everything there eventually? | |
| 15:01:52 | sdague | mordred: litterally, that's where we started | |
| 15:01:58 | mriedem | sdague: and if it comes to that, i'm basically going to punt for pike | |
| 15:02:14 | mriedem | and just deprecate os-virtual-interfaces as the easy thing we have to do anyway, we could lump that in with deprecating multinic | |
| 15:02:21 | sdague | mriedem: that's fine | |
| 15:02:24 | mriedem | johnthetubaguy: who knwos | |
| 15:02:31 | mriedem | johnthetubaguy: maybe eventually we do similar for bdms | |
| 15:02:37 | mordred | sdague: well, yah - it doesn't - because it's an extra call - I'm just saying it _is_ nice looking, so whoever wrote it didn't do a bad job or anything | |
| 15:02:40 | mriedem | GET /servers/{server_id}/volumes | |
| 15:03:04 | mriedem | johnthetubaguy: but in 2 years time when we talk about doing that, we'll have either all moved on or likely changed our minds and come to some other conclusion | |
| 15:03:12 | johnthetubaguy | mriedem: it feels like when they seems similar, we are closer to where we want to be | |
| 15:03:21 | mordred | sdague: if the addresses dict was instead list of those, that might be nice | |
| 15:03:22 | johnthetubaguy | +1 for deprecating the broken bits | |
| 15:03:36 | mordred | although I'd have to go poke for a minute to see how much code I could delete if it was | |
| 15:03:43 | sdague | ok, so I think that's where we stand, just deprecate the broken thing | |
| 15:03:45 | mriedem | how about microversion 2.43: completely rewrite the entire gd compute api? | |
| 15:03:55 | cdent | mriedem++ | |
| 15:04:01 | alex_xu | :) | |
| 15:04:27 | mriedem | because what i always think is an incremental step forward turns into a giant rewrite | |
| 15:05:07 | sdague | mriedem: yeh, they do have the natural tendancy to grow | |
| 15:05:17 | sdague | anyway, I think deprecate in a mv is fine | |
| 15:05:22 | sdague | that's a small change | |
| 15:06:19 | mriedem | alex_xu: if we just deprecate os-virtual-interfaces, i think we should combine that in the same microversion as deprecating multinic | |
| 15:06:27 | mriedem | so we don't have 20 separate microversions for just deprecating APIs | |
| 15:06:30 | alex_xu | mriedem: i'm ok with that | |
| 15:06:31 | mriedem | because that gets super annoying | |
| 15:06:42 | jaypipes | ya | |
| 15:06:49 | jaypipes | on the MV for 2 deprecations. | |
| 15:07:14 | alex_xu | do you want me merge that two spec? or we just approve the two spec separately, then I can help to code them together? | |
| 15:08:06 | alex_xu | and fyi, one more deprecation spec https://review.openstack.org/386888 :) | |
| 15:08:39 | mriedem | alex_xu: i don't think i ever liked that one | |
| 15:09:16 | mriedem | alex_xu: because of the very odd flow that the user has to do on the neutron side | |
| 15:09:25 | mriedem | to hook up a server with a floating ip via neutron | |
| 15:09:25 | alex_xu | mriedem: ok, I probably remember your point | |
| 15:09:46 | mriedem | it's all technically possible using the APIs, but the UX seems pretty terrible | |
| 15:09:55 | jaypipes | mriedem: pls see summary of mine on bottom of etherpad. | |
| 15:10:04 | mriedem | alex_xu: i've abandoned https://review.openstack.org/#/c/455023/ and we can just merge it into https://review.openstack.org/#/c/384261/ | |
| 15:10:15 | mriedem | alex_xu: since it's getting late for you, do you want me to just combine those? | |
| 15:10:27 | mriedem | then i can harass sean or jay or john to approve that today | |
| 15:11:01 | alex_xu | mriedem: will appreciate for that | |
| 15:11:10 | mordred | mriedem: the nova fip proxy api should never be used | |
| 15:11:18 | mordred | mriedem: it's racy and impossible to use atomically | |
| 15:11:32 | mordred | its use should be discouraged strongly | |
| 15:11:34 | johnthetubaguy | fip = floating ip? | |
| 15:11:36 | mordred | yah | |
| 15:11:38 | jaypipes | yes | |
| 15:11:57 | johnthetubaguy | mriedem: I think you removed that from alex_xu's original deprecation spec right? | |
| 15:11:59 | jaypipes | mordred, mriedem, sdague: does that summary on the etherpad make sense? | |
| 15:12:34 | mriedem | johnthetubaguy: originally alex_xu had deprecating floating ip actions and multinic in the same spec, and they were separated yes | |
| 15:12:57 | johnthetubaguy | ah, separated, I don't remember finding the other one I guess. | |
| 15:13:17 | egonzalez | Hi, it's been a recent change in master who change the behaviour in nova service-list? in current master output is empty with no service registered | |
| 15:14:00 | mriedem | mordred: you should read this then https://review.openstack.org/#/c/386888/4 | |
| 15:14:04 | mriedem | jaypipes: seems so | |
| 15:15:17 | johnthetubaguy | mriedem: do we want to include floating ip in your mega merged deprecated spec? | |
| 15:16:01 | amotoki | I totally agree that nova fip proxy is discouraged. on the other hand, it is sometimes useful i.e. in case of an instance has only one port. | |
| 15:16:20 | mriedem | johnthetubaguy: when i originally read the spec about deprecating the ability to associate/disassocate floating ips to servers and what you had to do in neutron for that, it seemed really complicated which is why i avoided it | |
| 15:17:09 | mriedem | neutron floatingip-create EXT_NET_ID | |
| 15:17:09 | mriedem | if it's really just: | |
| 15:17:14 | mriedem | neutron floatingip-associate FLOATING_IP_ID VM_PORT_ID | |
| 15:17:18 | mriedem | then that doesn't seem as bad | |
| 15:17:29 | amotoki | it is about CLI perspective. my comment is not applied to the API perspective and I thought so from when I implemented the neutron proxy... | |
| 15:17:51 | johnthetubaguy | mriedem : I think thats correct | |
| 15:17:58 | amotoki | yeah. I believe OSC can support it | |