This spec defines the Identity server side implementation of the Centralized Policy distribution as defined by the Keystone Middleware spec Centralized Policies Fetch and Cache [1]. Please refer to it for further background, motivation and use case information.
The Identity server will control the cache in endpoints through appropriate HTTP cache control headers, in order to keep policy consistent across different service endpoints which must have the same Centralized Policy, for example, multiple Nova processes running behind a proxy.
The proposed change is to add to the Identity server the capability to control policy cache in remote service endpoints by using the appropriate HTTP cache control headers.
This defines how long the retrieved policy is fresh for. This time delta will be defined in the Cache-Control HTTP header included in both GET /endpoints/{endpoint_id}/OS-ENDPOINT-POLICY/policy and GET /policies/{policy_id} responses. It will be respected by the Keystone Middleware implementation running at the service endpoints side.
In order to control the freshness for policy entities, the Identity server will have a config option called policy_cache_time to define the timeout.
If we call ‘checkpoint’ the event of timeout expiration, the freshness for a given policy is calculated based on the current time and when the next checkpoint will occur. Take the following situation as example:
The Identity server has ``policy_cache_time`` set to 300, i.e there is a
checkpoint every 300 seconds.
If there is a policy request 140 seconds after the last checkpoint, the
Identity server will return the policy and say it is only fresh for 160
seconds, when the next checkpoint will occur at the server side.
In order to keep policies consistent between endpoints which share the same Centralized Policy, the Identity server will create versions of policies, which are released every checkpoint.
When a policy request hits the Identity server, it will deliver the last released policy, ensuring that different endpoints asking the server at different times inside the policy_cache_time slice will get the same policy.
As a side effect, policy updates happening between two checkpoints will only take effect in the next release of that policy.
This problem can occur if policy_cache_time times out at the same time for all the policies in the system at the Identity server, then all the service endpoints would be asking for policy updates at the same time.
The proposed approach is to spread sets of endpoints which share the same policy over the time. This can be done by making the freshness of policies expires according a delay defined in fuction of their IDs, for example:
delay(policy-id) = hash(policy-id) % ``policy_cache_time``
Besides the cache control HTTP headers, the following will be specified:
None
None
No impact on server side, however some configuration impact is expected in the service endpoints side, in the Keystone Middleware configuration, as specified in the Keystone Middleware spec [1].
None
Primary assignee:
Other contributors:
A list of related specs defining the dynamic delivery of policies can be found under the topic dynamic-policies-delivery.
None besides the regular API documentation.