Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-02
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
18:31:48 mriedem this ci job doesn't include any pci stuff
18:32:05 mriedem so anything we're loading here is not used
18:37:48 efried The claimer doesn't log for PCI claims like it does for cpu, mem, and disk. So it's tough to tell if it *thinks* it's doing some kind of PCI claim.
18:42:47 openstackgerrit Chris Dent proposed openstack/nova master: Whether to use configdrive disk depends on instance.configdrive https://review.openstack.org/485930
18:52:30 efried cdent Would ^ this mean I could switch from `if configdrive.required_by(instance):` to `if instance.config_drive` in my driver?
18:53:15 cdent efried: sorry, don’t really know, I was just rebasing that to get it lined back up with the present
18:53:29 cdent sort of a rebase/recheck combo
18:53:47 efried Heh, okay. Yeah, it was after I said that that I realized you weren't really the author.
19:02:37 sdague mriedem: sure, I can take another cycle through it
19:23:48 openstackgerrit Merged openstack/nova-specs master: Add a spec for POST /allocations in placement https://review.openstack.org/499259
19:34:49 cdent jaypipes: except it’s not me he’s arguing with
19:35:11 jaypipes cdent: yes, sorry, with edleafe :)
19:35:18 efried whoah, something merged.
19:35:20 cdent but it is funny having the two most typo ridden people in the same place at the same time
19:35:24 cdent efried: i know, right?
19:36:14 sean-k-mooney jaypipes: :) semantics and grammer i understand, its spelling and typing i have issues with :)
19:36:14 cdent I find quite a lot of comfort in the fact the sean-k-mooney is a capable person and spells in the sae phonetically weird way that I do
19:36:21 jaypipes sean-k-mooney: :)
19:36:27 cdent see it just happened :)
19:37:37 sean-k-mooney well i have dyslexia so really phonetics is the best i can do without google/a spellcheck unfortunetly english spelling and phonetics rarely agree
19:38:31 openstackgerrit Sean Dague proposed openstack/nova master: Remove non libguestfs file injection for libvirt https://review.openstack.org/324720
19:38:54 edleafe I always felt "performant" was a BS word.
19:39:19 cdent sean-k-mooney: I’ve often wondered about this: Do you happen to know if dyslexia is both ways: read and write? I had assumed it was read ony?

Earlier   Later