Open Stack

> -----Original Message-----
> From: Chris Dent [mailto:cdent+os at anticdent.org]
> Sent: Monday, August 21, 2017 10:44 AM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] [placement] [api] cache headers in
> placement service
> 
> On Mon, 21 Aug 2017, Jay Pipes wrote:
> > On 08/21/2017 04:59 AM, Chris Dent wrote:
> > We do have cache validation on the server side for resource classes.
> > Any time a resource class is added or deleted, we call
> > _RC_CACHE.clear(). Couldn't we add a single attribute to the
> > ResourceClassCache that returns the last time the cache was reset?
> 
> That's server side cache, of which the client side (or proxy side) has
> no visibility. If we had etags, and were caching etag to resource pairs
> when we sent out responses, we could then have a conditional GET
> handler which checked etags, returning 304 on a cache hit.
> At _RC_CACHE changes we could flush the etag cache.
[Mooney, Sean K]  I agree this is likely needed if caching is used. One of the changes
Intel would like to make is to transition the attestation server integration for
Trusted boot with our cloud integrity technologies to use traits on the compute node
Instead of a custom filter to attest that the server is trusted. In that case we
We would want to ensure that if we add or remove a trait for resource provider that
The cache is invalidated. So we would have to invalidate the etag or updated everytime
We update the tratis.
> 
> > But meh, you're right that the simpler solution is just to not do
> HTTP
> > caching.
> 
> 'xactly
> 
> > But then again, if the default behaviour of HTTP is to never cache
> > anything unless some cache-related headers are present [1] and you
> > *don't* want proxies to cache any placement API information, why are
> > we changing anything at all anyway? If we left it alone (and continue
> > not sending Cache-Control headers for anything), the same exact
> result would be achieved, no?
> 
> Essentially so we can put last-modified headers on things, which in RFC
> speak we SHOULD do. And if we do that then we SHOULD make sure no
> caching happens.
> 
> Also it seems like last-modified headers is a nice-to-have for that
> "uknown client" I spoke up in the first message.
> 
> But as you correctly identify the immediate practical value to nova is
> pretty small, which is one of the reasons I was looking for the
> lightest-weight implementation.
> 
> --
> Chris Dent                      (⊙＿⊙')         https://anticdent.org/
> freenode: cdent                                         tw: @anticdent