Implement Cache Warm up and validation of Cluster tokens

[aslakknutsen]

Related https://github.com/fabric8-services/fabric8-auth/issues/282

• [x] Fetch all clusters and tokens on startup
• [x] Refresh cluster on a timer?
• [x] Token Validation https://github.com/fabric8-services/fabric8-tenant/commit/be8f39326808024c29ef6946151273359ae3e472

[aslakknutsen]

@alexeykazakov Thoughts to refresh interval here? These are statically configured in auth, so it would technically require a restart of auth for a new cluster to 'come online/token' be updated.

There are essentially 2 cases between tenant and osoproxy around this API:

• A new cluster is configured. A realistic time from Auth is configured to see a new cluster until the first user is provisioned. 1h?

(tenant & osoproxy)

• A cluster token is updated. (We currently only support 1 token per target?). Assuming we don't use non-expiring tokens; A admin would generate a new token before the old one expired and reconfigure Auth. How quickly should services start picking it up? In a controlled/normal situation I guess 1h is fine here as well. If a token is leaked and needs an immediate update, e.g. the app is failing now, 10 min? 5min? (or admin simply does a service restart to force update)

(tenant only)

Any ETag/If-Non-Match || Last-Modified/If-Modified-Since support in ClusterAPI atm?

[alexeykazakov]

A new cluster is configured. A realistic time from Auth is configured to see a new cluster until the first user is provisioned. 1h?

I think 1h is good enough. The flow is following:

1. Add new cluster to Auth config
2. Re-deploy Auth to pick up the new config
3. Sing up a new test user for the new cluster.
4. Provision/approve the test account to the new cluster and test it
5. Open up the cluster to public

We can easily wait for at least one hour between 2 and 4. Or re-deploy tenant service if we need it sooner.

We currently only support 1 token per target?

Correct.

A admin would generate a new token before the old one expired and reconfigure Auth. How quickly should services start picking it up? In a controlled/normal situation I guess 1h is fine here as well.

I think 1h is enough here too. We should generate a new token well before 1h I think :)

If a token is leaked and needs an immediate update, e.g. the app is failing now, 10 min? 5min? (or admin simply does a service restart to force update)

Yes, when we need to pick up tokens quicker (which is an emergency and not a routine operation) then we just restart all relevant services. 1) Update token 2) Restart Auth 3) Restart Tenant&Proxy. 2) and 3) should take less than a minute ;)

Any ETag/If-Non-Match || Last-Modified/If-Modified-Since support in ClusterAPI atm?

No. Cluster API is not supposed to be used too often at the moment. We can support caching later if/when we need it. To be clear. At Auth side of thinks it's super quick operation (we just return a tiny object stored in a map from memory). But even on the client side it's not a big deal to update the clusters every N minutes I think.

So, I think 1h is good enough. But even if we do it every 5-10 minutes I don't think it will change anything in terms of load. For example for Auth we currently refresh tokens every 10 minutes (for every user with opened browser) and a token refresh is much more expensive operation (the token signing part). Proxy and Tenant are busy too handling user requests.