Placement Minimum HTTP Cache Headers¶
RFC 7232#section-2.2 says that a web service should send a last-modified header for any representation for a last-modified time can reasonable be deduced. The placement service does not currently do this. Including it will make it a better HTTP citizen and also provide useful metadata in the response. If a last-modified header is added then it is also necessary to add a cache-control header with a value of “no-cache” to insure that clients and proxies are not inclined to cache representations provided by the placement service.
By not sending appropriate cache headers, placement is presenting two small problems:
It is not following accepted standards for HTTP services.
There is a chance that clients and proxies pasing requests to placement will cache responses from the service. Given that the majority of data provided by placement highly time dependent, this is problematic.
As a user of an HTTP API I expect it to follow standards and provide me with a
last-modified header that reflects the last modified time of the resource.
In a new microversion, for any
GET request handled by the placement service
add two additional headers in the response:
last-modifiedwith a meaningful time and data value (see below).
cache-controlwith a value of
no-cache. See RFC 7234#section-220.127.116.11 for additional detail on what this means.
The value of the
last-modified header is chosen from three different
If the request is for a singular entity directly associated with a database row that has an
created_atfield, then the value of one of those fields will be used, preferring
updated_atif it is set (it won’t be if the resource has only been created but not yet updated).
If the request is for a collection of entities that are directly associated with the database, the value will be the max of the
created_atfor all the entities in the collection.
If the request is for an entity or collection which is composed from multiple parts, then the value of the header will be the current time.
A viable alternative is to do nothing. If we don’t add the
headers then the risk of caching is very small (as there is no conditional
header present). But then we would be bad HTTP citizens.
Another alternatives is to start using ETags within the placement service.
This would enable fairly complex and complete server-side and client-side
caching of resources, saving bandwidth and database queries. It is, however, a
fairly serious undertaking and would not remove the need for
headers, so best to take smaller steps towards having the full suite of
Data model impact¶
The database tables already have the desired
fields but the OVO in
nova/objects/resource_provider.py need to be updated
to expose those fields. This can be done by using the
REST API impact¶
As stated, every GET request will get two additional headers
last-modified: <timestamp>. These will only be exposed in
the newly created microversion.
Other end user impact¶
If we consider the scheduler report client to be the primary “end user” of placement, these headers will have no impact on it, especially as the client uses explicit microversions in its requests.
A slight impact when requesting large collections. That collection is traversed to find the last-modified value. Most of this impact can be alleviated by combining that work in the existing traversal that creates the JSON response body.
Other deployer impact¶
When developers add new handlers for
GET requests to the placement service,
they will need to add these headers.
- Primary assignee:
- Other contributors:
Create a new microversion for this functionality
Update the objects in
nova/objects/resource_provider.pyto expose the
For each handler for a
GETrequest, add the headers
Updated gabbi tests to inspect the new headers and confirm their presence in the new microversion and lack of presence in older microversions
Update placement api-ref
As stated in the work items, it’s important to confirm that the headers show up as expected in the new microversion. It’s equally important to confirm that they do _not_ in older microversions.