[nova][ptg] Resurrecting NUMA topology in Placement
We discussed about a long known story https://review.openstack.org/#/c/552924/
The whole agreement during the PTG was to keep things simple with baby steps : - only supporting a few NUMA queries and defer others as unsupported (still supported by legacy NUMATopologyFilter) - The to-be-resurrected spec would be only focus on VCPU/PCPU/MEMORY_MB resource classes and not handle PCI or GPU devices (ie. level-1 tree, no children under the NUMA RPs)
Agreement was also there for saying that functional tests should be enough since PlacementFixture already works perfectly.
-S
On Tue, 2019-11-12 at 11:29 +0100, Sylvain Bauza wrote:
We discussed about a long known story https://review.openstack.org/#/c/552924/
The whole agreement during the PTG was to keep things simple with baby steps :
- only supporting a few NUMA queries and defer others as unsupported (still
supported by legacy NUMATopologyFilter)
- The to-be-resurrected spec would be only focus on VCPU/PCPU/MEMORY_MB
resource classes and not handle PCI or GPU devices (ie. level-1 tree, no children under the NUMA RPs)
Agreement was also there for saying that functional tests should be enough since PlacementFixture already works perfectly.
we can now do numa testing in the gate so we can also add tempest testing this cycle. artom has recently gotten whitebox to run (more work to do https://review.opendev.org/#/c/691062/) and i do want to get my multi numa nfv testing job https://review.opendev.org/#/c/679656/ at least in experimental and perodic pipelines. i would like it to be in check eventually but baby steps.
i dont think these should be a blocker for any of this work but i think we shoudl take advantage of them to contiue to improve the numa testing in gate.
-S
On Tue, 2019-11-12 at 13:26 +0000, Sean Mooney wrote:
On Tue, 2019-11-12 at 11:29 +0100, Sylvain Bauza wrote:
We discussed about a long known story https://review.openstack.org/#/c/552924/
The whole agreement during the PTG was to keep things simple with baby steps :
- only supporting a few NUMA queries and defer others as unsupported (still
supported by legacy NUMATopologyFilter)
- The to-be-resurrected spec would be only focus on VCPU/PCPU/MEMORY_MB
resource classes and not handle PCI or GPU devices (ie. level-1 tree, no children under the NUMA RPs)
Agreement was also there for saying that functional tests should be enough since PlacementFixture already works perfectly.
we can now do numa testing in the gate so we can also add tempest testing this cycle. artom has recently gotten whitebox to run (more work to do https://review.opendev.org/#/c/691062/) and i do want to get my multi numa nfv testing job https://review.opendev.org/#/c/679656/ at least in experimental and perodic pipelines. i would like it to be in check eventually but baby steps.
i dont think these should be a blocker for any of this work but i think we shoudl take advantage of them to contiue to improve the numa testing in gate.
by gate i ment ci/
-S
On Tue, Nov 12, 2019 at 2:30 PM Sean Mooney smooney@redhat.com wrote:
On Tue, 2019-11-12 at 13:26 +0000, Sean Mooney wrote:
On Tue, 2019-11-12 at 11:29 +0100, Sylvain Bauza wrote:
We discussed about a long known story https://review.openstack.org/#/c/552924/
The whole agreement during the PTG was to keep things simple with baby steps :
- only supporting a few NUMA queries and defer others as unsupported
(still
supported by legacy NUMATopologyFilter)
- The to-be-resurrected spec would be only focus on VCPU/PCPU/MEMORY_MB
resource classes and not handle PCI or GPU devices (ie. level-1 tree,
no
children under the NUMA RPs)
Agreement was also there for saying that functional tests should be
enough
since PlacementFixture already works perfectly.
we can now do numa testing in the gate so we can also add tempest
testing this cycle.
artom has recently gotten whitebox to run (more work to do
https://review.opendev.org/#/c/691062/)
and i do want to get my multi numa nfv testing job
https://review.opendev.org/#/c/679656/ at least
in experimental and perodic pipelines. i would like it to be in check
eventually but baby steps.
i dont think these should be a blocker for any of this work but i think
we shoudl take advantage
of them to contiue to improve the numa testing in gate.
by gate i ment ci/
Yup, I understood and we also discussed this possibility at the PTG. To be clear, that would be nice to get Tempest tests on a specific job that'd verify this, but this shouldn't be a blocker.
-S
participants (2)
-
Sean Mooney
-
Sylvain Bauza