| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-02-03 | |||
| 03:55:11 | EmilienM | if you run "check experimental" again, you should have debug = true on nova.conf | |
| 03:55:20 | mriedem | i also see the heat stack failed on instance not found http://logs.openstack.org/60/428360/2/experimental/gate-tripleo-ci-centos-7-nonha-multinode/6ca334c/console.html#_2017-02-02_20_42_31_044252 | |
| 03:55:22 | mriedem | so that killed it | |
| 03:55:27 | mriedem | anyway, talk to you tomorrow | |
| 03:55:35 | EmilienM | so this is a pingtest | |
| 03:55:42 | EmilienM | which means we weren't able to spawn a server | |
| 03:56:05 | EmilienM | http://logs.openstack.org/60/428360/2/experimental/gate-tripleo-ci-centos-7-nonha-multinode/6ca334c/logs/subnode-2/var/log/nova/nova-api.txt.gz#_2017-02-02_20_42_17_097 | |
| 03:56:26 | EmilienM | recheck the job (and check experimental), so you'll have DEBUG | |
| 03:56:30 | EmilienM | mriedem: good night | |
| 04:25:22 | mriedem | rc1 is basically ready to go i think https://review.openstack.org/#/c/428531/ | |
| 07:17:37 | openstackgerrit | Jiri Suchomel proposed openstack/nova master: Retry few times when creating the initial connection to libvirtd. https://review.openstack.org/416928 | |
| 07:28:43 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Should raise correct error instead of class exist in Placement API https://review.openstack.org/428612 | |
| 07:31:02 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Check destination_type when booting with bdm provided https://review.openstack.org/402372 | |
| 07:31:17 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Don't delete neutron port when attach failed https://review.openstack.org/403568 | |
| 07:36:07 | openstackgerrit | gecong proposed openstack/os-vif master: Delete H803 from ignore list https://review.openstack.org/428614 | |
| 07:38:14 | openstackgerrit | gecong proposed openstack/os-vif master: Delete H803 from ignore list https://review.openstack.org/428614 | |
| 08:16:34 | tdurakov | johnthetubaguy: hi, are you around? | |
| 08:40:24 | openstackgerrit | Hieu LE proposed openstack/nova master: Remove mox from unit/virt/libvirt/test_imagebackend.py (end) https://review.openstack.org/335925 | |
| 08:51:35 | openstackgerrit | Jeremy Liu proposed openstack/nova master: [3/3]Replace six.iteritems() with .items() https://review.openstack.org/415080 | |
| 08:58:53 | openstackgerrit | Andrey Volkov proposed openstack/nova master: Update pci device fields from deleted object https://review.openstack.org/426243 | |
| 08:59:17 | openstackgerrit | Silvan Kaiser proposed openstack/nova master: Removes getfattr from Quobyte Nova driver https://review.openstack.org/428646 | |
| 09:15:13 | sudipto | bauzas, hi, just a small query - if i have a property like cpuset, how do we represent that in the form of a inventory table data (of the new placement API). My doubt is - cpu set is a list of cpus, however the inventory field says: Total as one of the field attributes... | |
| 09:15:35 | sudipto | So how can i represent a cpuset inventory... | |
| 09:18:43 | openstackgerrit | Sergey Nikitin proposed openstack/nova master: Change parent of diagnostics objects to NovaObject class https://review.openstack.org/394480 | |
| 09:18:44 | openstackgerrit | Sergey Nikitin proposed openstack/nova master: Standardization of VM diagnostics info API. https://review.openstack.org/355540 | |
| 09:18:45 | openstackgerrit | Sergey Nikitin proposed openstack/nova master: Completed implementation of instance diagnostics for Xen https://review.openstack.org/399613 | |
| 09:35:04 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Should raise correct error instead of class exist in Placement API https://review.openstack.org/428612 | |
| 09:49:48 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Remove redundant bdm serial mangling and saving during swap_volume https://review.openstack.org/427364 | |
| 10:10:58 | bauzas | sudipto: sorry, missed your question | |
| 10:11:09 | sudipto | bauzas, np | |
| 10:11:37 | bauzas | sudipto: for the moment, we only have quantitave resources represented in the Placement PAI | |
| 10:11:49 | bauzas | sudipto: which are CPU usage, RAM and disk usage | |
| 10:11:54 | sudipto | bauzas, hmm ok. | |
| 10:12:46 | bauzas | sudipto: when saying cpu_set, which particular compute resource are you talking about ? | |
| 10:13:14 | sudipto | bauzas, https://github.com/openstack/nova/blob/master/nova/objects/numa.py#L47 this one... | |
| 10:13:20 | bauzas | sudipto: on the cpu pinning details | |
| 10:13:25 | bauzas | sudipto: I mean the NUMA things | |
| 10:13:48 | bauzas | sudipto: so, yeah, this one is targeted to be implemented thanks to a nested-resource-provided BP | |
| 10:14:05 | bauzas | basically, we'd say that that compute UUID == RP UUID | |
| 10:14:05 | sudipto | bauzas, yeah i read through this: https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/nested-resource-providers.html | |
| 10:14:34 | bauzas | and it would be parent of nested resource providers giving details on NICs or CPUs | |
| 10:14:51 | bauzas | sudipto: exactly, so FWIW it will be a pike thing | |
| 10:15:06 | sudipto | However, i could visualise how it would work for a numa_node's cpus or numa_node's memory (which would be qutitiative) - but if there's a set of cpus for a numa node, how do we represent it was my question... | |
| 10:15:35 | sudipto | since we have defined a "total" field in the inventory table. | |
| 10:18:45 | johnthetubaguy | tdurakov: sorry, late getting onto IRC this morning, hows things? | |
| 10:20:02 | johnthetubaguy | bauzas: good point on updating the allocations, that change just fixes the bleeding | |
| 10:20:26 | bauzas | sudipto: FWIW, I don't think cpu sets are quantitative amounts | |
| 10:20:35 | johnthetubaguy | bauzas: I have a feeling if you restart nova-compute, we end up writing out updated allocations, but I am not 100% sure on that, the code scares me lots | |
| 10:20:43 | bauzas | johnthetubaguy: so I asked yesterday | |
| 10:20:59 | bauzas | johnthetubaguy: and I've been told that periodic updates rewrite the whole allocations | |
| 10:21:05 | bauzas | so we should be good | |
| 10:21:19 | johnthetubaguy | bauzas: hmm, honestly, that sounds terrible, but it fixes the bug | |
| 10:21:21 | bauzas | but I can look at code | |
| 10:21:44 | johnthetubaguy | bauzas: I want to do that for the ironic change anyways, I don't get how that works right now | |
| 10:22:32 | sudipto | bauzas, but i am wondering that has to be accounted for in case of pinning cpusets | |
| 10:24:17 | bauzas | sudipto: I think a CPU set a list of differnet RPs with an inventory of a VCPU resource class with amount of 1 | |
| 10:24:38 | bauzas | sudipto: and all those RPs are nested children of a parent RP which is compute node | |
| 10:25:01 | sudipto | bauzas, ok so basically we will have to create RPs for each individual cpuset then? | |
| 10:25:25 | bauzas | sudipto: that's what I'd think but I'm not the mastermind :) | |
| 10:25:35 | sudipto | and then map that to a parent RP of numa_node and root RP of the compute node | |
| 10:25:43 | sudipto | ok, that sounds like a lot of queries to me. | |
| 10:25:44 | johnthetubaguy | I think the resource providers end up modelling the NUMA node topology, as nested resource providers | |
| 10:25:58 | bauzas | johnthetubaguy: that's what I said to sudipto | |
| 10:26:12 | bauzas | johnthetubaguy: the related question was rather how we model that in a nested RP world | |
| 10:26:19 | sudipto | yeah | |
| 10:26:32 | johnthetubaguy | did that go in the spec, i remember it being nasty | |
| 10:26:44 | bauzas | but like I said, I just think each cpu pin is a RP with an inventory of 1 | |
| 10:26:51 | sudipto | johnthetubaguy, didn't read that in the spec. I may have missed if it was there. | |
| 10:27:00 | bauzas | a NUMA cell would be a parent RP | |
| 10:27:05 | bauzas | of that CPU pin | |
| 10:27:17 | johnthetubaguy | The NUMA node child providers will have inventory records populated for the NUMA_CORE, NUMA_THREAD and NUMA_MEMORY_MB resource classes. | |
| 10:27:19 | bauzas | and a compute RP would be the parent of all NUMA cell RPs | |
| 10:27:24 | johnthetubaguy | http://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/nested-resource-providers.html#proposed-change | |
| 10:27:35 | bauzas | johnthetubaguy: right, but that doesn't mention the CPU pins | |
| 10:27:40 | sudipto | yeah | |
| 10:27:52 | johnthetubaguy | ah, gotcha | |
| 10:28:09 | johnthetubaguy | thats a qualitative problem, which I guess is what bauzas said earlier | |
| 10:28:17 | bauzas | johnthetubaguy: not really | |
| 10:28:24 | bauzas | johnthetubaguy: you need to *consume* a pin | |
| 10:28:40 | sudipto | yeah consume the pin quantitatively. | |
| 10:28:51 | bauzas | johnthetubaguy: hence my thinking of having a RP being the CPU pin itself | |
| 10:29:04 | bauzas | with an inventory of VCPU with amount of 1 | |
| 10:29:18 | johnthetubaguy | so there are a few sorts of pins right now, which one is this? | |
| 10:29:33 | bauzas | and pinning the CPU would mean writing an allocation against that inventory | |
| 10:29:41 | johnthetubaguy | really you care about getting a dedicated pCPU on the "correct" numa node, I thought? | |
| 10:29:58 | johnthetubaguy | or is this something else | |
| 10:30:04 | bauzas | johnthetubaguy: I'm considering the CPU-pinning feature we implemented in Nova | |
| 10:30:18 | bauzas | there are many ways to schedule the pinning | |
| 10:30:23 | bauzas | but AFAICT, we fully pin | |
| 10:30:47 | sudipto | we could choose to pin it to a NUMA node or choose to just pin a cpuset (older nova behaviour) | |
| 10:31:18 | bauzas | whatever | |
| 10:31:21 | sudipto | My problem is with the representation of the inventory data for cpusets itself with the current inventory field called 'total' | |
| 10:31:51 | bauzas | and ? | |
| 10:31:55 | johnthetubaguy | so the current inventroy doesn't work right, hence the need for nested, and the new resources of NUMA_CORE, etc | |
| 10:32:07 | bauzas | if you consider a single pCPU being a RP | |
| 10:32:25 | sudipto | so we start considering every single pCPU as a RP and then do what bauzas suggested. | |
| 10:32:27 | bauzas | with an VCPU inventory attached to it | |
| 10:32:28 | johnthetubaguy | well, no, I think a NUMA_CORE is a colleciton of pCPU, and you consume one of them | |
| 10:32:47 | johnthetubaguy | but I may have this upside down | |
| 10:32:51 | bauzas | johnthetubaguy: you mean a NUMA cell | |