| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-22 | |||
| 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 | |
| 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 | |
| 23:42:32 | sean-k-mooney | mriedem: which is why my tests are failing because i dont allow device id since the spec says it product_id | |
| 23:43:08 | mriedem | ok | |
| 23:43:10 | mriedem | ... | |
| 23:43:53 | sean-k-mooney | mriedem: im reworking https://review.openstack.org/#/c/449257 with stephenfin comments since rodolfo had to move on to opnfv work | |
| 23:44:30 | openstackgerrit | melanie witt proposed openstack/nova master: Detach volume after deleting instance with no host https://review.openstack.org/340614 | |
| 23:45:00 | sean-k-mooney | i think this is really just at test bug but it still hurts to look at the git blame. anyway i think ill get back to this in the morning since its almost midnight my time | |
| 23:57:37 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: List/show all server migration types (1/2) https://review.openstack.org/430608 | |
| #openstack-nova - 2018-01-23 | |||
| 00:07:38 | mriedem | i'm +2 on the OSC CLI change for show/set/delete allocations https://review.openstack.org/#/c/457534/ - i think that's a good one to get in before the final client release freeze this week (same day as FF) | |
| 00:08:12 | mriedem | best way to review these i've found is pull them down to your devstack and kick the tires | |
| 00:10:31 | melwitt | mriedem: is there something special that has to be done to use the osc-placement plugin with OSC? I tried to use it last week and failed to figure it out. there were no 'openstack placement' or 'openstack resource' commands available | |
| 00:10:54 | mriedem | melwitt: git clone the repo, | |
| 00:10:57 | mriedem | then pip install it | |
| 00:11:02 | mriedem | then just: openstack resource provider -? | |
| 00:11:05 | mriedem | for the list of commands | |
| 00:11:36 | melwitt | okay. in my devstack it was installed and I even tried pip removing and pip installing it again with no luck. I'll try it again | |
| 00:12:14 | melwitt | that is, the osc-placement package got installed by devstack by itself (I didn't do anything to install it manually) | |
| 00:12:20 | mriedem | hmm, did you have the latest version of the osc-placement repo? | |
| 00:12:25 | mriedem | oh... | |
| 00:12:33 | melwitt | no, it took whatever was on pypi | |