Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-22
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: WIP: Use update_provider_tree from resource tracker https://review.openstack.org/520246
23:38:05 openstackgerrit Eric Fried proposed openstack/nova master: Fix nits in update_provider_tree series https://review.openstack.org/531260
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:06 openstackgerrit Eric Fried proposed openstack/nova master: ProviderTree.get_provider_uuids: Top-down ordering https://review.openstack.org/536624
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
23:41:27 melwitt (corrects self) er, or there shouldn't be two cells with dupe DB connection or dupe MQ URL
23:41:28 mriedem sean-k-mooney: well you'll be happy to know it's just a json blob of whackiness so it doesn't matter https://github.com/openstack/nova/blob/master/nova/objects/instance_pci_requests.py#L32
23:41:54 openstackgerrit Merged openstack/nova master: Generalize DB conf group copying https://review.openstack.org/484908
23:41:55 sean-k-mooney mriedem: thats what im changing at stephenfin request
23:42:17 openstackgerrit Merged openstack/nova master: Recreate mediated devices on reboot https://review.openstack.org/533642

Earlier   Later