Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-11
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
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 mriedem rpodolyaka: ok
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: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 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:35:41 mriedem oh btw https://review.openstack.org/#/c/453272/
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. :)
15:42:21 mordred mriedem: are clouds using searchlight yet?
15:43:36 mriedem mordred: no idea
15:45:00 mriedem mordred: searchlight wasn't listed in the oct 2016 user survey report anyway
15:46:53 mriedem mordred: well let me introduce you to https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/list-instances-using-searchlight.html
15:47:10 mriedem mordred: you're going to end up wasting your entire gd day in this channel
15:48:17 mordred mriedem: luckily I like all of you people
15:48:59 sdague mriedem: after a couple of hours yesterday, I did figure out why my flake8 in buffer checking didn't like the order import extension. It's that it's out of the box behavior isn't what we use
15:49:33 sdague and that if the file being run on it is outside of the tox tree (and there are reasons tools do that) it then behaves differently
15:49:34 mordred mriedem: neat!
15:50:10 sdague anyway I have a work around, but as this is the second time that flake8-import-order caused an issue, I do kind of wonder if we really want to keep it, https://review.openstack.org/#/c/454853/
15:51:04 mriedem sdague: i have no opinion on it, and haven't had issues with it
15:51:27 sdague mriedem: it broke the intel ci, again, because it does things by just being installed
15:51:46 mriedem because it's in nova?
15:52:10 sdague well, it used to be in test-requirements
15:52:17 sdague which means it impacted things system wide
15:53:26 mriedem it's not in test-requirements anymore though
15:53:29 sdague it's not
15:53:39 sdague now it's this other problem

Earlier   Later