| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-11 | |||
| 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: :) | |
| 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 | mordred | mriedem: yes- but it does it in one step | |
| 15:20:42 | jaypipes | sdague: and technically, we could add a ports/ subresource listing before deprecating os-interface. | |
| 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 | |
| 15:23:03 | mordred | johnthetubaguy: speaking of kevinbenton ... I just realized that my ssh-hostkey spec should actually be a neutron feature not a nova feature, so I'm going to be bugging kevinbenton about it and not you | |
| 15:23:19 | rpodolyaka | mriedem: hey! you asked about https://review.openstack.org/#/c/381912/ yesterday. It's not on the top of my list, but yes, I was hoping either me or snikitin_ will take over it from pkholkin | |
| 15:23:32 | openstack | Launchpad bug 1642918 in neutron "floating-ip nova notification is broken" [High,Fix released] - Assigned to YAMAMOTO Takashi (yamamoto) | |
| 15:23:32 | mriedem | rpodolyaka: ok | |
| 15:23:34 | mordred | johnthetubaguy: it's entirely possible, yes - but we have since learned to not trust that data as it's proxy data and just go directly to the source | |
| 15:23:41 | mordred | johnthetubaguy: AWESOME | |
| 15:23:48 | sdague | jaypipes: the old version continues to work as well, this is just the new prefered way. The old one isn't going to get dropped any time soon. | |
| 15:23:50 | johnthetubaguy | mordred: yeah, that makes sense | |
| 15:23:55 | alex_xu | mordred: under 'neutron floatingip-create EXT_NET_ID VM_PORT_ID' is one API or multiple API? | |
| 15:23:56 | mordred | johnthetubaguy: that does, in fact, sound like the problem we saw :) | |
| 15:24:17 | mordred | alex_xu: well, I honestly don't know about the neutron command line client- but there is a single REST API for create-with-port | |
| 15:24:21 | mordred | one sec, lemme find it for you | |
| 15:24:26 | amotoki | alex_xu: it is a single API except name lookup | |
| 15:24:45 | alex_xu | mordred: amotoki, ah, that is cool | |
| 15:25:18 | mriedem | alex_xu: mordred: https://developer.openstack.org/api-ref/networking/v2/index.html?expanded=show-port-details-detail,create-floating-ip-detail#create-floating-ip | |
| 15:25:28 | mriedem | POST /v2.0/floatingips with a port_id in the body | |
| 15:25:30 | mordred | mriedem: yah | |
| 15:25:32 | mordred | that'sit | |
| 15:25:38 | mriedem | "To associate the floating IP with an internal port, specify the port ID attribute in the request body. If you do not specify a port ID in the request, you can issue a PUT request instead of a POST request." | |
| 15:26:14 | mordred | (this API is 100% of the reason I want port_ids on fixed ips reported in the nova server record, fwiw) | |
| 15:26:37 | alex_xu | amotoki: I remember we can't do that in single API in long time before? | |
| 15:28:10 | mordred | sdague, jaypipes: so - don't hate me - but I do actually think net_id and subnet_id are also useful alongside the port_id in the addresses dict - largely because if I only have port_id I'll still have to go do a GET on the port to find out what network it's from so I can match it to cached information I've figured out about which networks are public and which are private | |
| 15:28:12 | mordred | SO | |
| 15:28:51 | mordred | if it's possible to add it when you add port_id without any additional cost - it is very useful (and still isn't duplicating all the additinonal info) | |
| 15:29:13 | sdague | mordred: so... I think it's pushing it to put all of that in the server doc | |
| 15:29:29 | sdague | in the subresource, sure | |
| 15:29:59 | mordred | sdague: adding three ids adjacent to the ip is pushing it? | |
| 15:30:02 | jaypipes | sdague: yeah, that's what I was referring to... as in "we still will duplicate information for a time being" :) | |
| 15:30:10 | mordred | I mean, you already have the port_id in ram when you're building addresses and just delete it | |
| 15:30:39 | jaypipes | mordred: sure, I hear ya. it's more of an efficiency thing, as we discussed. | |
| 15:30:40 | sdague | mordred: it's mostly about the constant everyone wants everything they might ever need in the server document | |