Due to the not strict handling of uninitialized fields during notification payload population it is possible that the emitted notification missing some of the fields defined in the schema. There are two problematic cases: 1) no load tirggered for lazy loaded fields. If the field was not loaded it is not added to the payload. 2) uninitialized, not lazy loadable fields are not added to the payload. This patch makes sure that lazy load is triggered. If the field is not lazy loadable and also not initialized then related payload field will be set to None. If the payload field is not nullable the code will fail to make sure that the inconsistency is detected. The following changes cannot be split to different commits because as soon as the generic schema population code is fixed every listed notification starts behaving differently. In some cases the availability_zone field of the Service object is left unitialized by both the constructor and the obj_load_attr function this caused that the availability_zone field of the service.update notification was missing from the emitted notification payload. The extra_specs field of the Flavor object is not lazy loadable and not initialized in the Flavor destroy case. So the extra_specs field of the FlavorPayload needed to be made nullable. The projects field of the Flavor object is lazy loaded but when the Flavor object is loaded as part of an Instance object Flavor is orphaned and no lazy load is allowed on that Flavor object. In this case the projects field of the FlavorPayload will be set to None to signal that the information is not available. This also means that the projects field of the FlavorPayload needed to be changed to nullable. The hosts and id fields of the Aggregate object is not initialized during the create of the Aggregate before the aggregate.create.start needs to be sent. Therefore these fields needs to be nullable. Closes-Bug: #1653221 Change-Id: Ib122cd98ee0cc31938d5ff1d5c753053267a3bd4
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 and OpenStack Ironic.
OpenStack Nova is distributed under the terms of the Apache License, Version 2.0. The full terms and conditions of this license are detailed in the LICENSE file.
API
To learn how to use Nova's API, consult the documentation available online at:
http://developer.openstack.org/api-guide/compute/ http://developer.openstack.org/api-ref/compute/
For more information on OpenStack APIs, SDKs and CLIs, please see:
http://www.openstack.org/appdev/ http://developer.openstack.org/
Operators
To learn how to deploy and configure OpenStack Nova, consult the documentation available online at:
For information about the different compute (hypervisor) drivers supported by Nova, please read:
http://docs.openstack.org/developer/nova/feature_classification.html
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: