| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-11 | |||
| 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 | |
| 15:31:08 | sdague | and we're trying to resist that a bit | |
| 15:31:17 | mordred | sure. but it's not everything they might ever need -it's the two foreign keys you need to know how to take action on the server from a networking perspective. | |
| 15:32:08 | sdague | mordred: so, I think it's just time to walk away on this one, because the whole thing got dropped from pike about 30 minutes ago when it overran mriedem's rage level | |
| 15:32:16 | mordred | ok | |
| 15:32:48 | mordred | I'd _love_ to dig in to find the right thing whenver it's the right time to do that - but I totally grok rage level on this topic | |
| 15:33:30 | mriedem | johnthetubaguy: alex_xu: so given the above discussion, maybe we do just merge the deprecation of add/removeFloatingIP with add/removeFixedIP (multinic), and also throw os-virtual-interfaces deprecation in there as well | |
| 15:33:53 | johnthetubaguy | mriedem: I am very tempted by that | |
| 15:34:12 | mriedem | johnthetubaguy: don't let me seduce you, you're married proper now | |
| 15:34:45 | mriedem | mordred: sdague: jaypipes: yeah i'm running as far away from fixing bdms and ports in the compute API as i can for pike | |
| 15:34:52 | mriedem | because both attempts crushed both balls | |
| 15:35:12 | jaypipes | mriedem: fine with me. | |
| 15:35:18 | jaypipes | mriedem: sorry for complaining. | |
| 15:35:38 | johnthetubaguy | mriedem: :) | |
| 15:35:41 | mriedem | oh btw https://review.openstack.org/#/c/453272/ | |
| 15:35:41 | mordred | mriedem: well, please let me know if/when the topic comes up again. I'm definitely both very interested, very opinionated and often very confused | |
| 15:36:03 | sdague | mordred: yeh, well the issue is not a lack of opinions for sure.... | |
| 15:36:14 | jaypipes | mriedem: apparently, Tommy *doesn't* Like. | |
| 15:37:22 | mordred | sdague: :) | |
| 15:40:36 | mriedem | jaypipes: since you championed server tags in the comptue api, you might want to chime in on this cinder thread to do similar for volume tags http://lists.openstack.org/pipermail/openstack-dev/2017-March/114618.html | |
| 15:40:49 | mriedem | because the reply right now is, 'use searchlight' | |
| 15:41:09 | jaypipes | mriedem: that would mean I want to tell DuncanT that he's wrong again. :) | |