| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-02 | |||
| 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 | |
| 18:01:59 | mriedem | heh, so of the 4 things we pull out of that limits dict in tree for the claim, we have numa, disk, ram and cpu | |
| 18:02:06 | mriedem | but we also do a pci requests claim test, | |
| 18:02:16 | mriedem | but the pci requests are persisted somewhere, and not part of the limits dict | |
| 18:02:19 | mriedem | that's, fun | |
| 18:04:52 | mriedem | oh but they are in the request spec | |
| 18:05:50 | mriedem | which we of course pass down to the compute, but we don't use | |
| 18:07:58 | mriedem | oh but even if we did, it wouldn't have the pci_requests in it, because the version of the request spec that the conductor passes down to the compute isn't the one that the api creates | |
| 18:08:00 | mriedem | gfdi | |
| 18:08:09 | mriedem | melwitt: ^ seems we were just talking about some crazy shit like this last week | |
| 18:08:58 | mriedem | this is what conductor always builds and passes to the compute (which is then ignored): https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L78 | |
| 18:19:21 | oomichi | mriedem: she takes one year vacation now for a new baby. Maybe other guys from our company will take care of https://review.openstack.org/#/c/389482 | |
| 18:20:22 | oomichi | mriedem: is it fine to just create a corresponding blueprint? | |
| 18:20:50 | mriedem | oomichi: yes i think a specless blueprint is fine | |
| 18:20:59 | mriedem | it's just the vcenter driver supporting a new vif type, correct? | |
| 18:22:02 | oomichi | mriedem: ok, I will take. I need more time for detail to understand anyways | |
| 18:24:29 | mriedem | sdague: were you going to polish this up again at some point? https://review.openstack.org/#/c/324720/ | |
| 18:24:34 | efried | mriedem In driver.spawn, I see instance.pci_requests with useful stuff in it. | |
| 18:24:39 | mriedem | i'm about to start working on the file injection deprecation spec | |
| 18:24:57 | mriedem | efried: i think that's because we lazy-load it out of instance.pci_requests | |
| 18:25:07 | mriedem | we basically have pci_requests all over the place | |
| 18:25:35 | mriedem | when the basic dict request spec is converted to a full object and sent to the scheduler, we set the reqspec.pci_requests = instance.pci_requests | |
| 18:25:37 | efried | mmkay. I wasn't totally understanding what you were talking about above, but I knew I had seen basically everything I needed about the PCI request in the instance object. | |
| 18:25:49 | mriedem | but don't pass that objectified reqspec down to the compute, or use it in the compute | |
| 18:26:03 | efried | "the compute" like where? | |
| 18:26:11 | mriedem | efried: just general confusion over how things are done and where and why they are done differently | |
| 18:26:33 | mriedem | efried: conductor passes a simplified dict form of the request spec to build_and_run_instance on the compute | |
| 18:26:39 | mriedem | but that request spec parameter is never used in the compute | |
| 18:26:48 | mriedem | the resource tracker queries the database to get any pci requests for the instance | |
| 18:27:49 | mriedem | also, that's probably why we see lots of "lazy-loading pci_requests" in the compute logs during CI runs | |
| 18:28:48 | efried | yeah, I see that | |
| 18:29:05 | efried | in my local one-spawn test | |
| 18:29:12 | mriedem | http://logs.openstack.org/04/506104/1/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/39f64c6/logs/screen-n-cpu.txt.gz | |
| 18:29:19 | mriedem | just search for "lazy-loading" | |
| 18:29:34 | efried | 97 | |
| 18:30:00 | efried | oh, it hadn't finished loading. | |
| 18:30:05 | efried | I guess it's lazy-loading the page :) | |
| 18:30:14 | mriedem | yeah, 455 | |
| 18:30:25 | mriedem | 186 for pci_devices | |
| 18:30:26 | efried | 186 hits when I include 'pci-devices' | |
| 18:30:27 | efried | yeah. | |
| 18:31:02 | efried | Well, the good news is that'll make it easier to rip out later | |
| 18:31:04 | mriedem | pci_requests is only 16 | |
| 18:31:28 | efried | Presumably because only 16 of 'em requested PCI devices? | |
| 18:31:35 | mriedem | no | |
| 18:31:40 | mriedem | but not really sure | |