
Previously, SchedulerReportClient.set_inventory_for_provider used this logic to pre-create custom resource classes found in the input inventory. list(map(self._ensure_resource_class, (rc_name for rc_name in inv_data if rc_name not in fields.ResourceClass.STANDARD))) ...where _ensure_resource_class would always attempt to create the resource class it was given, and raise an exception if that failed for any reason. Note in particular that attempting to create an already-extant "standard" resource class will fail just the same as attempting to create any nonexistent resource class that doesn't conform to the schema (i.e. beginning with "CUSTOM_"). The problem is that this relies on the local system's notion of the set of standard resource classes. If the placement service is running newer code, standard resource classes may have been added that the compute service doesn't know about yet. This change set solves the problem by only attempting to create resource classes with the 'CUSTOM_' prefix. self._ensure_resource_class (which worked on a single resource class) is replaced with self._ensure_resource_classes (plural) which accepts a list of *all* the desired resource classes (including the standard ones), filters down to the CUSTOM_* ones, and attempts to create the remainder. Note that if placement ever decides to start allowing creation of resource classes with prefixes other than CUSTOM_, it will have to do so under a new microversion, so we can't future-proof this by e.g. prefetching all the known resource classes from placement and attempting to create any not found in that list. In the process of doing this rework, obsolete code paths relying on pre-1.7 placement microversions are removed. Change-Id: I600ed262e1b5d11facbf461e28291193665280cf Closes-Bug: #1746615
Team and repository tags
OpenStack Nova
OpenStack Nova provides a cloud computing fabric controller, supporting a wide variety of compute technologies, including: libvirt (KVM, Xen, LXC and more), Hyper-V, VMware, XenServer, OpenStack Ironic and PowerVM.
Use the following resources to learn more.
API
To learn how to use Nova's API, consult the documentation available online at:
For more information on OpenStack APIs, SDKs and CLIs in general, refer to:
Operators
To learn how to deploy and configure OpenStack Nova, consult the documentation available online at:
In the unfortunate event that bugs are discovered, they should be reported to the appropriate bug tracker. If you obtained the software from a 3rd party operating system vendor, it is often wise to use their own bug tracker for reporting problems. In all other cases use the master OpenStack bug tracker, available at:
Developers
For information on how to contribute to Nova, please see the contents of the CONTRIBUTING.rst.
Any new code must follow the development guidelines detailed in the HACKING.rst file, and pass all unit tests.
Further developer focused documentation is available at:
Other Information
During each Summit and Project Team Gathering, we agree on what the whole community wants to focus on for the upcoming release. The plans for nova can be found at: