| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-02 | |||
| 14:52:31 | openstackgerrit | zhangyangyang proposed openstack/nova master: Remove ExactDiskFilter https://review.openstack.org/508893 | |
| 14:54:38 | mriedem | -2ed then | |
| 15:02:21 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/newton: Add live.migration.force.complete to the legacy notification whitelist https://review.openstack.org/508902 | |
| 15:11:20 | openstackgerrit | Matt Riedemann proposed openstack/python-novaclient stable/newton: Fix aggregate_update name and availability_zone clash https://review.openstack.org/507816 | |
| 15:16:31 | mriedem | gmann: oomichi: you could probably help direct this a bit https://review.openstack.org/#/c/389482/ | |
| 15:16:37 | mriedem | looks like it's NEC | |
| 15:24:17 | openstackgerrit | zhangyangyang proposed openstack/nova master: Remove ExactCoreFilter ExactDiskFilter ExactRamFilter https://review.openstack.org/508886 | |
| 15:26:18 | openstackgerrit | zhangyangyang proposed openstack/nova master: Remove ExactCoreFilter ExactDiskFilter ExactRamFilter https://review.openstack.org/508886 | |
| 15:31:06 | openstackgerrit | zhangyangyang proposed openstack/nova master: Remove ExactCoreFilter ExactDiskFilter ExactRamFilter https://review.openstack.org/508886 | |
| 15:34:20 | sean-k-mooney | johnthetubaguy: just as an fyi im going to update https://review.openstack.org/#/c/375580 and reporpose for queens if you have no objection | |
| 15:34:47 | johnthetubaguy | sean-k-mooney: sounds good | |
| 15:54:46 | openstackgerrit | Chris Dent proposed openstack/nova-specs master: Add trait support in the allocation candidates API https://review.openstack.org/497713 | |
| 16:00:23 | mriedem | dansmith: sdague: remember the discussion at the ptg about making the ip filtering more efficient when listing instances? | |
| 16:00:46 | mriedem | i thought about something that would be problematic with one of the proposed solutions, which was querying neutron ports first, | |
| 16:00:56 | mriedem | i don't think neutron has a concept like "read_deleted=yes" | |
| 16:01:37 | mriedem | so if you did: nova list --ip 192.168.159.128 --deleted --all-tenants | |
| 16:01:56 | mriedem | i don't think we'd be honoring the --deleted flag if we first filtered by IP using neutron | |
| 16:02:05 | dansmith | mriedem: you mean parallelizing the neutron and nova work, yeah | |
| 16:02:19 | dansmith | mriedem: we'd just get a larger set back than we need and would filter it ourselves | |
| 16:02:30 | mriedem | my understanding of what was proposed was first call neutron to get the list of ports (device_ids) per the ip filter provided | |
| 16:02:54 | mriedem | and then use ^ to filter the results from the cells | |
| 16:03:44 | dansmith | right, but we could still not return things that are deleted | |
| 16:03:48 | dansmith | oh | |
| 16:03:49 | mriedem | you could still honor --deleted if you only did the python filtering on any deleted instances in the results from the cells...but you're still probably wasting time checking which of the 1000 instances are deleted | |
| 16:03:51 | dansmith | I see what you mean | |
| 16:03:58 | dansmith | you don't get back the deleted ips | |
| 16:04:02 | mriedem | right | |
| 16:04:03 | dansmith | I read your logic backwards | |
| 16:04:04 | dansmith | yeah | |
| 16:04:08 | dansmith | but | |
| 16:04:20 | mriedem | but they could be deleted from nova anyway....or archived | |
| 16:04:22 | dansmith | deleted things can be purged at any time, so not being able to satisfy that query doesn't seem terrible to me | |
| 16:04:24 | dansmith | right | |
| 16:04:36 | mriedem | i know we used that as justification for some things in my searchlight spec | |
| 16:04:39 | mriedem | so it could apply here | |
| 16:04:47 | dansmith | and for flavor things I think | |
| 16:04:49 | sdague | so... honestly, I think we need to decouple "as an admin I need to ..." | |
| 16:04:54 | sdague | and it needs to be in the API | |
| 16:05:28 | sdague | because a lot of these things are a pretty straight forward combination of API calls, that if exposed as a single command in openstack client might be sufficient | |
| 16:05:54 | dansmith | well, we said that too yeah | |
| 16:06:07 | dansmith | I think we said we need to ask the people that need to do this if that would be okay | |
| 16:07:20 | sdague | yeh | |
| 16:07:28 | sean-k-mooney | sdague: shade may also be an option for those that want a programatic interface | |
| 16:09:44 | sdague | sean-k-mooney: sure, though if we're really talking about quick search functions, I think openstack client is probably the thing people will be using | |
| 16:10:21 | mriedem | i see notes in the etherpad about the idea for doing it in osc, but nothing saying we were going to ask about that | |
| 16:11:26 | mriedem | if you force it client side, then it has to be duplicated everywhere | |
| 16:11:57 | sdague | mriedem: but that's kind of ok | |
| 16:12:23 | sdague | because this is typically a debug operation | |
| 16:12:35 | sdague | something goes wrong with an ip, and track it back to source | |
| 16:13:38 | finucannot | mriedem: Just to confirm, this doesn't need a microversion because it's a bug? | |
| 16:13:39 | finucannot | https://review.openstack.org/#/c/490722/11 | |
| 16:14:07 | sdague | I'm also super unclear whether the regex part of this is really interesting or should be supported | |
| 16:14:17 | dansmith | yeah, that was another question I think | |
| 16:14:32 | mriedem | stephenfin: not just b/c it's a bug, some bugs require microversions | |
| 16:14:42 | mriedem | stephenfin: we discussed it at the ptg, the notes are in https://etherpad.openstack.org/p/nova-ptg-queens | |
| 16:14:50 | mriedem | L657 | |
| 16:15:21 | stephenfin | mriedem: So it's a bug and there was never any chance of these requests succeeding? | |
| 16:16:20 | mriedem | stephenfin: yes, the api would pass but the thing would eventually fail, so it never worked, so there was no point in doing a microversion, since 2.1 wouldn't work anyway | |
| 16:19:12 | stephenfin | mriedem: Cool cool. +Wd | |
| 16:33:14 | openstackgerrit | Chris Dent proposed openstack/nova-specs master: Spec for limiting GET /allocation_candidates https://review.openstack.org/504540 | |
| 16:33:42 | cdent | jaypipes, mriedem, edleafe, sean-k-mooney, rgerganov, efried, gibi: made ^ way less complicated | |
| 16:33:53 | cdent | but may be too simple now for some people | |
| 16:48:29 | mriedem | ok. i've got a couple of specs i need to write before tomorrow's sprint, so that's first priority for me (after lunch of course) | |
| 16:48:38 | mriedem | plus some other performance and scale testing threads i need to pull | |
| 16:48:53 | dansmith | jaypipes: so on the selection thing, I'm not okay with making limits an unversioned json string, and I think we probably need to take an approach like you suggested earlier | |
| 16:49:19 | jaypipes | dansmith: having a specific numa_limits field, right? | |
| 16:49:32 | dansmith | jaypipes: question though.. the numa limit object we get from the filter (right?) ... doesn't that depend on the host we've chosen? like, will that numa limit object apply to the alternate hosts? | |
| 16:49:44 | dansmith | or can we pull out the one that applies to the selection we're doing? | |
| 16:49:48 | dansmith | jaypipes: yeah, that | |
| 16:50:14 | jaypipes | dansmith: yes, absolutely the NUMA limits applies to a host. | |
| 16:51:52 | dansmith | jaypipes: right and the second part is, will we be able to populate this selection object with a numa limit that applies to the host the selection is for? | |
| 16:52:49 | openstackgerrit | zhangyangyang proposed openstack/nova master: Update zuul user gating html https://review.openstack.org/508941 | |
| 16:56:30 | openstackgerrit | zhangyangyang proposed openstack/nova master: Update zuul user gating html https://review.openstack.org/508941 | |
| 17:05:00 | jaypipes | dansmith: yes, that will be necessary. will add comment to review shortlyu. | |
| 17:05:46 | jaypipes | git rebase --continue | |
| 17:05:54 | jaypipes | guh, wrong window, sorry... | |
| 17:06:32 | cdent | jaypipes: on your review of the limit stuff, you seemed to miss a section | |
| 17:06:57 | jaypipes | cdent: erm... | |
| 17:12:27 | jaypipes | cdent: see my last review. | |
| 17:13:07 | cdent | yup | |
| 17:40:20 | cdent | thanks dansmith | |
| 17:40:39 | dansmith | cdent: did it merge? | |
| 17:41:11 | dansmith | zuul hasn't even noticed, AFAICT | |
| 17:41:39 | cdent | not yet, but having a spec not be fraught with debate is enough to say thank you to | |
| 17:41:52 | dansmith | heh | |
| 17:42:01 | cdent | it’s in the gate | |
| 17:42:57 | cdent | but spinning | |
| 17:49:25 | mriedem | dansmith: jaypipes: were you talking about the selection object re: the numa limits stuff? | |
| 17:49:32 | dansmith | yeah | |
| 17:49:38 | jaypipes | mriedem: yes | |
| 17:50:44 | mriedem | ok, if we're going to intentionally break out of tree filters that rely on injecting stuff into the limits dict, we should have a release note on that at least | |
| 17:51:49 | dansmith | s/intentionally/knowingly/ | |
| 17:55:59 | mriedem | so the long-term goal here is we don't even need that numa topology limits thing in the selection object right? because eventually we don't even do that claim in the compute at all | |
| 17:56:21 | mriedem | maybe it's a custom resource class or something? | |
| 17:56:21 | dansmith | it's used for more than that in compute isn't it? | |
| 17:56:36 | mriedem | not sure, i haven't traced it through it's usage beyond the claim | |
| 17:57:06 | dansmith | I thought it was used for the libvirt setup of the numaness | |
| 17:59:24 | mriedem | yeah it is | |
| 17:59:31 | mriedem | used to create the guest xml in the libvirt drivre | |
| 17:59:33 | mriedem | *driver | |