Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-22
22:24:54 mriedem right?
22:26:30 hongbin mriedem: yes, so the proposal said "make the device_id of floating ip same as the instance uuid"
22:26:51 hongbin then, nova uses the uuid as the device_id to query
22:27:05 hongbin s/uuid/instance uuid/
22:27:43 mriedem umm
22:28:31 mriedem so (1) list all instances, (2) then call neutron with all of those instance uuids to get the ports AND also filter the floating IPs from that list of ports by the provided floating IP substring match?
22:29:02 mriedem the port.device_id is the same as the instance uuid already
22:29:13 mriedem the port and floating IP have a relationship somewhere
22:29:29 mriedem so if you can list/filter ports by floating IP, you can build a list of server uuids
22:29:40 sean-k-mooney mriedem: i think the owner of teh floating ip in neutron is the port uuid
22:30:36 sean-k-mooney so really what you want to do is say neutron give be the owner of the port that has this uuid
22:30:43 sean-k-mooney * floating ip
22:31:37 hongbin (2) is performed only if users insert the --floating-ip filter when listing the instances
22:36:12 hongbin mriedem: yes, it is confusing, i will ask the bug reportor to clarify
22:38:19 mriedem if the request is just, "do the same thing as the ip filter but for floating ips when listing instances" then that's easy to understand
22:38:42 mriedem the ip filter works on fixed ips, the floating ip filter (being requested) works on floating ips
22:38:45 sean-k-mooney hongbin: mriedem this is the basic workflow today http://paste.openstack.org/show/650595/
22:40:11 sean-k-mooney the device id of the neutron port is the nova instance id so today tyou do a floating ip show by it ip then get the port_id it is bound to look up the port and then get the device id of the port
22:40:14 mriedem sean-k-mooney: the floating IP has a fixed IP on it
22:40:18 mriedem so,
22:40:21 mriedem nova list --ip 172.20.50.10
22:40:22 mriedem done
22:40:32 sean-k-mooney the fixed ips can overlap
22:41:00 sean-k-mooney e.g. one tenant can have two networks with the same subnet
22:41:06 mriedem i have a request,
22:41:12 mriedem can one of you hand me that shotgun in the corner?
22:42:04 sean-k-mooney if its any concilation the floating ip has to be unique. i think...
22:43:38 sean-k-mooney mriedem: if the floating ip show included the device id direclty would that work for you
22:44:03 mriedem sean-k-mooney: any of this being handled outside of nova works for me
22:44:05 sean-k-mooney then its jsut nova show ${device-id}
22:44:33 sean-k-mooney well to be honest its only 3 command today
22:44:51 sean-k-mooney i can proably make that a 1 liner with fome bash foo
22:45:24 mriedem so is creating a volume of a specific type and then creating a server from that volume, but people have always wanted to proxy through the volume type for boot from volume
22:45:26 sean-k-mooney i think the real issue is if you support regex or partical matches on the ip in stead of exact match
22:45:27 mriedem because bash is hard
22:46:46 sean-k-mooney mriedem: thats fair was the original request to do this in the client or api
22:46:58 hongbin the scalability is also an issue, i.e. how to list the instances with a specific floating ip when there are thousands of instances
22:48:15 melwitt mriedem: easy fix for 'nova-manage cell_v2 update_cell' where it wasn't excluding 'self' in its search for duplicate DB connection or transport URL https://review.openstack.org/#/c/536546/
22:48:46 mriedem sean-k-mooney: the api
22:49:15 mriedem hongbin: if you filter the ports by the floating ip first, then you've already narrowed down the instances because the port has the device_id
22:50:03 hongbin mriedem: i see, if what they want is one instance, then it is not a problem
22:50:46 hongbin if they want a list instances with a floating ip prefix, then it is
22:51:20 sean-k-mooney hongbin: well the oneline is openstack server show $(openstack port show $(openstack ip floating show 172.20.64.168 --column port_id -f value) -f value --column device_id) but yes you would have to call this for all instance in the prfix in a loop
22:51:55 hongbin sean-k-mooney: ack
22:51:56 sean-k-mooney so ideally you would extend floating ip list to accpet a cider to match agenst
22:52:39 sean-k-mooney and also add the device id to the floating ip so you can just do a show on the nova instance that the end
22:53:25 dansmith efried: got it
23:00:21 mriedem melwitt: ack; currently trudging through internal email backlog of misery
23:01:04 sean-k-mooney hongbin: mriedem looking at https://developer.openstack.org/api-ref/network/v2/#list-floating-ips
23:01:27 sean-k-mooney hongbin: mriedem what we really want in the neutron api is the ablity to do /v2.0/floatingips/?floatingip=<cidr>&fields=device_id
23:02:22 sean-k-mooney the blocker being current floatingip=<cidr> has to be an exact match not a cider and the port device_id is not returned as part of the floating_ip object
23:03:25 hongbin sean-k-mooney: yes, agree
23:04:29 hongbin if neutron supports matching floating ip prefix, and adding the device_id to the floating ip resource, it seems to resolve the problem
23:05:02 efried dansmith Thank you sir. Now if we can just get zuul to cooperate
23:05:09 dansmith good luck
23:05:44 efried ikr. It's been awful last couple weeks.
23:06:38 sean-k-mooney hongbin: based on http://specs.openstack.org/openstack/neutron-specs/specs/api/networking_general_api_information.html#filtering-and-column-selection they already support some simple filtering so addign cidr support should be possible instead of exact match
23:08:00 hongbin sean-k-mooney: yes, technically, it is an easy job
23:09:23 sean-k-mooney well you say that but it depends on where the filtering is done. if its in sql whic i would guess it is based on what is currently supported that less trivial
23:11:44 hongbin i think what needs to be done in neutron side is to change the sql query from '==' to 'like'
23:12:32 hongbin e.g. input==<exact_floating_ip> to input.like('%floating_ip_substring%')
23:13:10 sean-k-mooney hongbin: if you wnat to suport queries like all fluting ips containing "192.168" yes but you cant say all floating ips in 192.168.1.0/24
23:13:27 sean-k-mooney im not sure what the original goal was
23:14:34 hongbin yes, i also a bit confusing, asking my colleague to clarify
23:14:37 sean-k-mooney adding the device_id to the floating ip need a change to the floating ip api which i think is defiended in neutron-lib and that cant be reved until rocky as we are past the non-client lib freeze
23:15:03 hongbin yes, know that
23:16:52 sean-k-mooney hongbin: i was just checking for my own sake but this is what would have to be modified https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/l3.py#L103-L137
23:18:19 hongbin sean-k-mooney: like this https://review.openstack.org/#/c/534882/1/neutron_lib/api/definitions/fip_device_id.py ?
23:18:47 hongbin so i already have a poc for that
23:19:04 sean-k-mooney hongbin: oh haha yes exactly like that :)
23:19:30 hongbin :)
23:21:39 sean-k-mooney hongbin: so ya all that is missing then is adding support for a partial match on the floating ip so input==<exact_floating_ip> to input.like('%floating_ip_substring%') as you said above
23:22:35 hongbin yes, and also need a clear picture that how nova will use it
23:23:38 sean-k-mooney prosumably nova would call /v2.0/floatingips/?floatingip=<ip substing>&fields=device_id then do a a server list for each insance uuid returned.
23:24:10 sean-k-mooney but mriedem could comment on that better then i ^
23:25:10 mriedem i think i said that like an hour ago
23:25:18 mriedem "do the same thing as the ip filter but with a floating ip"
23:25:28 mriedem question was why does nova need to add this proxy filter support at all
23:27:52 sean-k-mooney i think when this came up in the ptg i liked the idea of the neutorn change but fealt the nova change did not need to be in the api and could be in the client
23:27:58 openstackgerrit Matt Riedemann proposed openstack/python-novaclient master: Add support for microversion 2.60 - volume multiattach https://review.openstack.org/536621
23:28:48 mriedem sean-k-mooney: this floating ip filtering thing didn't come up in denver
23:29:05 mriedem at least that i can recall - we talked about how to improve the performance of the *existing* ip filter when listing instances
23:29:18 mriedem and that's done: https://review.openstack.org/#/c/525505/
23:29:59 sean-k-mooney mriedem: are you sure im pretty sure i asked migle about adding the api change to neutron in dever
23:30:27 sean-k-mooney mriedem: oh maybe that is what im thinking about
23:31:06 sean-k-mooney mriedem: so this is the same just adding support for floating ip
23:31:53 mriedem sounds like it yes
23:34:19 mriedem melwitt: dansmith: so on https://review.openstack.org/#/c/536546/ we're just wanting to like change the name of an existing cell right?
23:34:44 dansmith mriedem: or puppet is just running update_cell all the time because that's how it works
23:35:09 dansmith s/all the/every/
23:35:30 dansmith like, there's probably a piece of puppet that says "ensure that cell0 has db url $foo and mq url $bar" and they just run update_cell blindly
23:35:32 melwitt mriedem: yeah, the update name would be one but the situation reported in the bug was that update_cell is not idempotent
23:36:26 mriedem alright
23:36:31 melwitt I think it would also fail if you wanted to change only one of DB connection or transport URL with update_cell
23:36:40 dansmith right
23:36:45 dansmith well,
23:36:58 dansmith no, I think it shouldn't because that wouldn't match one of the existing ones right?
23:37:17 melwitt it would match one of them with itself (before the fix) I think
23:37:34 dansmith oh you're right, it's an or
23:37:37 dansmith so yeah

Earlier   Later