| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-11 | |||
| 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 | |
| 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 | 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:45 | sdague | jaypipes: I think that 2 & 3 have to happen at the same time along with droping the os-interface resource | |
| 15:19:53 | mordred | mriedem: :) | |
| 15:20:13 | jaypipes | sdague: os-interface, sure, but not os-virtual-interfaces, right? | |
| 15:20:20 | mordred | if you use the single-api-call create-with-port version in places you know you want to create-and-attach, then it is possible to know that unattached fips are available | |
| 15:20:21 | sdague | jaypipes: correct | |
| 15:20:26 | mriedem | so "neutron floatingip-create EXT_NET_ID VM_PORT_ID" creates a floating ip on EXT_NET_ID and then associates that to a fixed ip on VM_PORT_ID? | |
| 15:20:34 | mordred | if you do the create/attach dance, you are always racing | |
| 15:20:41 | johnthetubaguy | mordred: yeah, make sense | |
| 15:20:42 | jaypipes | sdague: and technically, we could add a ports/ subresource listing before deprecating os-interface. | |
| 15:20:42 | mordred | mriedem: yes- but it does it in one step | |
| 15:20:52 | mordred | mriedem: so you never have a fip show up in a non-attached state | |
| 15:21:18 | sdague | jaypipes: we could, but it would mostly create 1 mv where there was a funny duplication | |
| 15:21:23 | mordred | mriedem: (we used to have to run a fip cleaner thread in nodepool before switching to the single-call neutron api) | |
| 15:21:33 | jaypipes | sdague: sure, understood. | |
| 15:21:38 | johnthetubaguy | mordred: not sure if the generation id they are adding to ports helps with that, I guess its a pattern they could use elsewhere | |
| 15:21:54 | mordred | johnthetubaguy: I haven't heard about this generation id | |
| 15:22:00 | jaypipes | sdague: though we'd need to deprecate os-interface for a while anyway, so there'd still be a duplication period. | |
| 15:22:23 | johnthetubaguy | mordred: kevinbenton I think knows about that, for atomic port updates | |
| 15:22:31 | mordred | neat. I like atomic things | |
| 15:22:40 | sdague | jaypipes: we actually don't | |
| 15:22:51 | jaypipes | sdague: no? | |
| 15:22:58 | sdague | jaypipes: no, it's a microversion change | |
| 15:23:01 | johnthetubaguy | mordred: I was curious on your comment about server metadata getting out of sync, is that given the clouds you are using? They might not have the bug fix in them | |