| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-23 | |||
| 14:19:13 | bauwser | leakypipes: https://twitter.com/sylvainbauza/status/977187898167611392 | |
| 14:20:34 | giblet | bauwser: lol | |
| 14:21:18 | openstackgerrit | Merged openstack/nova master: remove _cleanup_running_deleted_instances repeat detach volume https://review.openstack.org/554090 | |
| 14:21:34 | openstackgerrit | Merged openstack/nova master: deprecate fping_path config option https://review.openstack.org/526602 | |
| 14:22:09 | mriedem | there is no reason we need to warn for this right? http://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py#n3340 | |
| 14:22:22 | mriedem | the user is trying to do something the api allows them to do, so the operator shouldn't be warned about it | |
| 14:22:46 | mriedem | https://git.openstack.org/cgit/openstack/nova/tree/nova/compute/api.py#n2717 | |
| 14:22:51 | bauwser | I think it's time for me writing a new rev' for NUMA and stating the concerns in the spexc | |
| 14:25:07 | cdent | my laptop battery and my brain battery are dying | |
| 14:26:13 | bauwser | cdent: take a power bank | |
| 14:26:31 | cdent | bauwser: you got one for brains? hook me up | |
| 14:26:33 | bauwser | cdent: that said, I can't perclue where to plug the bank | |
| 14:27:35 | bauwser | s/perclue/guess | |
| 14:28:03 | bauwser | note for self, stop buying expensive nespresso machines that are just subject to failures | |
| 14:28:23 | bauwser | and start finding other ways for making coffee | |
| 14:29:58 | openstackgerrit | Tyler Blakeslee proposed openstack/nova master: Add __repr__ for NovaException https://review.openstack.org/555812 | |
| 14:31:35 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Allow scheduling only to enabled cells (Filter Scheduler) https://review.openstack.org/550527 | |
| 14:31:36 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Add --enable and --disable options to nova-manage update_cell https://review.openstack.org/555416 | |
| 14:31:36 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Modify nova-manage cell_v2 list_cells to display "disabled" column https://review.openstack.org/555415 | |
| 14:31:37 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Add disabled option to create_cell command https://review.openstack.org/555417 | |
| 14:35:20 | sahid | leakypipes: ++ on you spec cpu-resources | |
| 14:38:51 | bauwser | leakypipes: time for a question ? | |
| 14:39:14 | bauwser | leakypipes: about https://review.openstack.org/#/c/555081/3/specs/rocky/approved/cpu-resources.rst@249 and beyond | |
| 14:39:32 | leakypipes | bauwser: sure | |
| 14:39:39 | leakypipes | sahid: +2 on tx/rx | |
| 14:39:47 | leakypipes | sahid: I will let mriedem +W it though | |
| 14:39:47 | bauwser | leakypipes: just noting a few things on the spec | |
| 14:40:04 | bauwser | leakypipes: sahid: the TX/RX was next in my review queue | |
| 14:40:05 | superdan | leakypipes: mriedem said he was leaving it to us in the meeting, so I think you can +W | |
| 14:40:14 | bauwser | I have a fucking low number of reviews this week | |
| 14:40:55 | leakypipes | superdan: got it. done. | |
| 14:41:19 | leakypipes | bauwser: reading specs takes a long time... | |
| 14:41:28 | sahid | superdan thanks for having so active on it | |
| 14:41:42 | superdan | sahid: s/having/being/ | |
| 14:41:50 | leakypipes | :) | |
| 14:41:52 | sahid | :) | |
| 14:44:40 | mriedem | kashyap: i updated https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix for queens and added the ubuntu 18.04 LTS package versions based on https://packages.ubuntu.com/bionic/allpackages | |
| 14:44:46 | figleaf | leakypipes: quick question about the spec. When there are NUMA nodes with V/PCPU inventory, and a non-granular request is received, will there be allocation candidates returned for every possible combination of NUMA providers? | |
| 14:44:48 | mriedem | looks like all of the other distros in that table are old | |
| 14:45:00 | kashyap | mriedem: Ah-ha. I have it open in one tab | |
| 14:45:11 | kashyap | And was reviewing your historical changes there yesterday | |
| 14:45:17 | mriedem | kashyap: so since we didn't bump in queens, | |
| 14:45:18 | kashyap | Will get to it, once I respond to this bug-from-hell downstream | |
| 14:45:35 | mriedem | we already have a 'next min version' in the driver, which is actually kind of old now, libvirt 1.3.1 | |
| 14:45:37 | leakypipes | figleaf: yes, alloc candidates would contain alloc requests against each NUMA node that had space to fit the sum amount of requested VCPU/PCPU | |
| 14:45:48 | mriedem | the question is then what will the next min version be in Solar | |
| 14:45:53 | kashyap | What is Solar? | |
| 14:45:54 | leakypipes | figleaf: I can add a note to clarify that. | |
| 14:45:57 | kashyap | A new Ubuntu version? | |
| 14:46:01 | mriedem | solar is next openstack | |
| 14:46:12 | mriedem | (pending that name is approved by legal) | |
| 14:46:15 | kashyap | Aah, I didn't check the release naming for the next one | |
| 14:46:32 | leakypipes | I guess my suggestion of "Suck It, Trebek" didn't fly. | |
| 14:46:57 | figleaf | leakypipes: that's what I thought. When an a-c is chosen and allocated against, is there anything that constrains the building of the VM to the particular NUMA node that was allocated against? | |
| 14:47:32 | bauwser | figleaf: leakypipes: reviewed | |
| 14:47:33 | openstackgerrit | Merged openstack/nova-specs master: libvirt: add support for virtio-net rx/tx queue sizes https://review.openstack.org/539605 | |
| 14:47:33 | leakypipes | figleaf: nothing besides the provider UUID, no. | |
| 14:48:14 | bauwser | figleaf: leakypipes: my main concern is that existing flavors that don't ask for NUMA specifics shouldn't be constrained on NUMA nodes | |
| 14:48:25 | figleaf | leakypipes: and there is no relation between the RP UUID in placement and a particular NUMA node in hardware, right? | |
| 14:48:45 | leakypipes | bauwser: they aren't "constrained". they just end up on a NUMA node is the host system is NUMA.. | |
| 14:48:52 | leakypipes | s/is/if/ | |
| 14:48:59 | bauwser | leakypipes: back up a second | |
| 14:49:12 | bauwser | leakypipes: I'm taking the example I had previously | |
| 14:49:20 | bauwser | say I ask for two VCPUs, period. | |
| 14:49:48 | bauwser | what if my compute only has only vCPU left on one NUMA node, but one other vCPU left on another NUMA node ? | |
| 14:49:59 | bauwser | at the moment, nova will satisfy that | |
| 14:50:18 | leakypipes | bauwser: if the host system is NUMA, then the VCPU inventories will be against child provider representing NUMA nodes. And the allocation candidates will contain allocation requests that consume against one of those NUMA node resource providers. | |
| 14:50:25 | bauwser | because the strategy is "spread" between all NUMA nodes, except if you clearly ask for another strategy | |
| 14:50:37 | leakypipes | bauwser: in that case, that compute node would not be returned. | |
| 14:50:46 | leakypipes | bauwser: since no single provider has capacity for 2 VCPU | |
| 14:50:51 | bauwser | leakypipes: that's the whole point I discussed previously | |
| 14:51:02 | bauwser | leakypipes: that's a behavioural change | |
| 14:51:36 | bauwser | from a placement perspective, what was successful before is no longer possible | |
| 14:52:19 | leakypipes | bauwser: then don't have the host configured to create NUMA node resource providers. | |
| 14:52:30 | leakypipes | bauwser: and just use a single provider for the comute node. | |
| 14:53:05 | bauwser | leakypipes: so only specific NUMA workloads would run on a NUMA-specified compute, and non-NUMA workloads would end up on the rest ? | |
| 14:53:24 | bauwser | if that's a config option, the default value would be "flat topology" | |
| 14:53:38 | leakypipes | bauwser: not following you... how is that different from today? | |
| 14:54:06 | bauwser | leakypipes: today you can end up having non-NUMA workloads that are running on a NUMA compute | |
| 14:54:32 | bauwser | actually | |
| 14:54:34 | bauwser | sec | |
| 14:54:44 | bauwser | doing huge pages and CPU pinning would be insane | |
| 14:54:54 | bauwser | if some workloads would just pick any CPU | |
| 14:55:03 | leakypipes | bauwser: yes, and there's nothing in the new system that would change that. the operator simply wouldn't set up the compute host to create NUMA child providers on that host (if this is really an issue that anyone is concerned about)( | |
| 14:55:47 | bauwser | leakypipes: okay, I see your point, how the operator would drive whether they want a non-NUMA inventory or not ? | |
| 14:55:53 | bauwser | thru a config option ? | |
| 14:56:09 | leakypipes | bauwser: that's up to your spec, no? :) | |
| 14:56:15 | bauwser | fair enough :) | |
| 14:56:44 | bauwser | okay, I think that's a reasonable trade-off | |
| 14:58:36 | figleaf | bauwser: that's what I meant here [t 3hcx] | |
| 14:58:36 | purplerbot | <figleaf> bauwser: "only in root" - that was one of the decisions we made back in Atlanta. A machine would be configured by the operator ahead of time. If a VCPU was assigned to a NUMA node, it could not be considered also to be part of the root compute node [2018-03-23 14:06:19.844755] [n 3hcx] | |
| 15:00:01 | bauwser | figleaf: yeah, what changed now is that I think that most operators already shard their cloud in between hosts that supports NUMA workloads and others (thru aggregates I guess) | |
| 15:00:19 | bauwser | because doing CPU pinning requires that your host is pretty dedicated for | |
| 15:00:48 | bauwser | I'm not saying you were wrong :) | |
| 15:01:13 | figleaf | bauwser: of course not! :) | |
| 15:02:45 | mlavalle | rybridges: hi, when you have a chance, plese look here: https://github.com/openstack/neutron/blob/stable/ocata/neutron/services/segments/plugin.py#L232. As you can see, after adding the hosts to the aggregate, it adds the IPv$ inventory to the RP. Was the inventory created? | |
| 15:09:02 | sean-k-mooney[m] | leakypipes: so just finished the v3 of the spec. i like this much more but some nits inline | |
| 15:09:14 | leakypipes | sean-k-mooney[m]: cool, ty sir | |
| 15:09:29 | leakypipes | sean-k-mooney[m], cfriesen: wanted to make sure I got all the definitions crystal clear... | |
| 15:09:45 | leakypipes | sean-k-mooney[m], cfriesen: did I properly describe vCPU threads, emulator threads and I/O threads? | |