ee47beb3be
A variety of changes are required to allow the various entities
presented by the placement API to have last-modified times.
According to the HTTP 1.1 RFC headers last-modified headers SHOULD always
be sent and should have a tie to the real last modified time. If we do
send them, we need Cache-Control headers to prevent inadvertent caching
of resources.
This patch provides necessary changes to the database and object
handling that will support the API changes made in a followup patch.
The main steps are:
* map base.NovaTimestampObject to ovo.TimestampedObject
* Add the base.NovaTimestampObject mixin to the relevant object in
nova/objects/resource_provider.py
* Tweak queries to retrieve updated_at and created_at fields where
they are not already present
Note that only those objects which are directly represented in response
bodies and directly associated with a database resource that has
created_at and updated_at fields are changed (e.g., resource providers).
Other objects, like usage and allocaiton candidates, which are
composites and represent the state of the universe _now_, will use the
current time when they get last-modified headers in the next patch.
Some HTTP requests, such as GET /resource_providers/{uuid}/aggregates
are based on a association that happens at a time that is not recorded
and is ambiguous: should we tell last-modified time of the most recently
created aggregate uuid, or the time when the association between a
resource provider and an aggregate was made (which we don't know). In
those cases where a solution is unclear, no object or database changes
are made, and the next patch will use the current time in any related
last-modified headers.
Change-Id: I3f6310af9c5bea682e793d27d480952aa8776d61
Partial-Bug: #1632852
Partially-Implements: bp placement-cache-headers
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: