| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-22 | |||
| 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 | |
| 23:38:04 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: SchedulerReportClient.update_from_provider_tree https://review.openstack.org/533821 | |
| 23:38:05 | openstackgerrit | Eric Fried proposed openstack/nova master: Fix nits in update_provider_tree series https://review.openstack.org/531260 | |
| 23:38:05 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Use update_provider_tree from resource tracker https://review.openstack.org/520246 | |
| 23:38:06 | openstackgerrit | Eric Fried proposed openstack/nova master: ProviderTree.get_provider_uuids: Top-down ordering https://review.openstack.org/536624 | |
| 23:38:06 | openstackgerrit | Eric Fried proposed openstack/nova master: Move refresh time from report client to prov tree https://review.openstack.org/535517 | |
| 23:38:07 | openstackgerrit | Eric Fried proposed openstack/nova master: set_{aggregates|traits}_for_provider: tolerate set https://review.openstack.org/536625 | |
| 23:38:14 | sean-k-mooney | mriedem: this makes me sad https://github.com/openstack/nova/blob/master/nova/tests/unit/objects/test_instance_pci_requests.py#L26-L53 device_id should be product_id according to https://github.com/openstack/nova/blob/master/doc/source/admin/pci-passthrough.rst and other tests | |
| 23:38:17 | melwitt | yeah. historically it was an 'and' but recently it was changed to an 'or' since global MQ can't be a thing anyway and each cell should have unique DB and transport URL combo | |
| 23:39:21 | sean-k-mooney | mriedem: unless wew chanded for device_id to product id a some point. those thest have been using incorrect mocks for 3 years | |
| 23:39:43 | mriedem | sean-k-mooney: that's a pci request, not a port | |
| 23:40:09 | mriedem | or you're just talking about something different and i have no idea | |
| 23:40:51 | sean-k-mooney | mriedem: sorry yes this was what i was working on before the floating ip conversation | |