As discussed during PTG, there was a consensus written in https://etherpad.openstack.org/p/nova-ptg-pike-placement L66 about Ironic flavors needing to add extra specs for the Placement service to know which resources to verify. Basically, every Ironic flavor (corresponding to a type of flavor) will require a specific extra spec that will describe a custom resource class, distinct from every one Ironic custom resource class. Eg., say that you have two ironic flavor corresponding to two hardware types, one reflecting HPE hardware and one reflecting Dell h/w, then the first flavor would add "resources:CUSTOM_IRON_HPE" as an extra spec, while the second would be "resources:CUSTOM_IRON_DELL" The formal specification document describing the operator impact is still on-going, I'll update the BZ once it's proposed.
First of all, I'm really surprised nobody from Ironic got involved here. Second, this work has just landed, and I'm not even sure it has landed completely. While it *might* work in Pike, I personally was not able to make it work even on DevStack. Ed Leafe was looking into it a few days ago. I suggest we don't rush into it during the Pike time frame. For Queens, I suggest our two teams get to a planning board and come up with a solid migration plan before proceeding. We need to migrate both ironic nodes (set resource_class) and nova flavors (set extras) *before* upgrade to Queens (i.e. before nova-compute is restarted). This has to be documented for ironic in the overcloud, but it has to happen automatically for the undercloud. Please keep Ramon (our PM, cc'ed) and me in the loop. Thanks!
Dmitry - IIRC I spotted code in pike for handling this on the undercloud, so it's just a doc change for the overcloud remaining?
Yep, the undercloud was migrated in Pike by https://github.com/openstack/instack-undercloud/commit/16961722c5b87766b4aed536589a20c2f05e1170. The upstream tripleo-docs were updated in https://github.com/openstack/tripleo-docs/commit/b93a87a75ae924d93dbb9154398e45a0246c758b. I guess downstream docs need an update as well now.
(In reply to Dmitry Tantsur from comment #4) > I guess downstream docs need an update as well now. Do we need to move this bz to the docs component then? Otherwise, if there's nothing else left to do, close it as... UPSTREAM?
I guess moving it to documentation may be helpful.
Hi Docs folks, My understanding is that what's needed is to reflect the upstream docs change [1] in our downstream docs. Cheers! [1] https://github.com/openstack/tripleo-docs/commit/b93a87a75ae924d93dbb9154398e45a0246c758b
SME: Piotr Kopec <pkopec>
This bug has been closed as NOTABUG because the requested content already exists in our documentation as part of the procedures for designating Compute nodes, for example: * Designating Compute nodes for CPU pinning: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/configuring_the_compute_service_for_instance_creation/assembly_configuring-compute-nodes-for-performance_compute-performance#proc_designating-compute-nodes-for-cpu-pinning_cpu-pinning * Designating Compute nodes for PCI passthrough: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/configuring_the_compute_service_for_instance_creation/assembly_configuring-pci-passthrough_pci-passthrough#proc_designating-compute-nodes-for-pci-passthrough_pci-passthrough * Designating Compute nodes for vGPU: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/configuring_the_compute_service_for_instance_creation/assembly_configuring-virtual-gpus-for-instances_vgpu#proc_designating-compute-nodes-for-vgpu_configuring-vgpu If you believe this bug has been closed in error, please re-open and provide a comment telling us what additional documentation you require, and provide a link to your active support case. Thank you for your help!