Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-22
22:16:47 mriedem the best thing is probably to add something to neutron to allow filtering ports by floating IP substring?
22:17:35 hongbin yes, if nova is removing proxies to neutron, then this request doesn't seem to fit into the scope
22:18:47 hongbin yes, this can be done
22:19:04 hongbin however, the question from neutron team is if this will be used by nova
22:19:13 mriedem it won't,
22:19:20 mriedem unless we plumb something into the compute API to proxy that through when listing servers
22:19:31 hongbin yes, get it
22:20:20 hongbin mlavalle: ping, fyi (above)
22:20:38 mriedem if the requestor says, "well then i get the device_id from the port(s) and then i have to call the compute API to get server details and that's too much work" then i'd ask what they need from the server details beyond just the server uuid
22:21:35 openstackgerrit Merged openstack/nova master: libvirt: Collocate encryptor and volume driver calls https://review.openstack.org/460243
22:21:51 openstackgerrit Merged openstack/nova master: libvirt: Introduce disk encryption config classes https://review.openstack.org/464008
22:22:05 openstackgerrit Merged openstack/nova master: [api] Allow multi-attach in compute api https://review.openstack.org/271047
22:22:20 efried mriedem dansmith Easy fix, one +2 already, can I get a quick look please? https://review.openstack.org/#/c/536545/
22:23:33 hongbin mriedem: my understanding is that they want a new filter in nova (i.e. nova list --floating-ip <xxx>), and under the hook, nova calls neutron api with the device_id to query the floating ips
22:24:12 hongbin and the addition of device_id in neutron side is for nova to query the floating ips fast
22:24:53 mriedem hongbin: we do'nt know the device_id until we get the ports, which would be filtered by the floating IP the user passes in
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

Earlier   Later