Earlier  
Posted Nick Remark
#openstack-nova - 2017-04-11
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 sdague mordred: you just said that did you no good :P
15:01:44 mriedem sdague: honestly it's a lot more than i was planning to do for this
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 alex_xu mriedem: ok, I probably remember your point
15:09:25 mriedem to hook up a server with a floating ip via neutron
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 if it's really just:
15:17:09 mriedem neutron floatingip-create EXT_NET_ID
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
15:18:29 mriedem it could also be,
15:18:31 mordred mriedem: that's the bad version
15:18:35 johnthetubaguy mriedem: the network changed event bit was missing out that original spec, not sure if that was also a possible blocker
15:18:43 mordred mriedem: neutron floatingip-create EXT_NET_ID VM_PORT_ID
15:18:46 mriedem whenever i need to read through the docs on how to associate a floating ip to a server in docs.o.o, i can't figure it out
15:18:47 mordred is actually the good way
15:18:49 mordred it's a single call
15:19:03 johnthetubaguy mordred: bad version? I am curious?
15:19:04 johnthetubaguy oh
15:19:05 mriedem johnthetubaguy: no i remember that part
15:19:26 mriedem mordred: but neutron cli is deprecated :)
15:19:45 sdague jaypipes: I think that 2 & 3 have to happen at the same time along with droping the os-interface resource
15:19:45 mordred johnthetubaguy: the reason is that if you have multiple api accessors, and any of them want to attempt to re-use unattached floating ips, they have no way of knowing if a fip that is in the flow of being created/attached is actually up for grabs or not
15:19:53 mordred mriedem: :)

Earlier   Later