Open Stack

Excerpts from 王玺源's message of 2017-02-17 14:08:30 +0000:
> Hi David:
> 
> We have not find the perfect solution to solve the fernet performance
> issue, we will try the different crypt strength setting with fernet in
> future.
> 

One important thing: did you try throwing more hardware at Keystone?
Keystone instances are almost entirely immutable (the fernet keys
are the only mutable part), which makes it pretty easy to scale them
horizontally as-needed. Your test has a static 3 nodes, but you didn't
include system status, so we don't know if the CPUs were overwhelmed,
or how many database nodes you had, what its level of activity was, etc.

> 
> 
> There are multiple customers have more than 6-region cascade, how to
> synchronous keystone data between these region disturbed us a lot. It does
> not need to synchronize these data while using pki token, because the pki
> token including the roles information.
> 

The amount of mutable data to synchronize between datacenters with Fernet
is the fernet keys. If you set up region-local caches, you should be
able to ship queries back to a central database cluster and not have to
worry about a painful global database cluster, since you'll only feel
the latency of those cross-region queries when your caches are cold.

However, I believe work was done to allow local read queries to be sent
to local slaves, so you can use traditional MySQL replication if the
cold-cache latency is too painful.

Replication lag becomes a problem if you get a ton of revocation events,
but this lag's consequences are pretty low, with the worst effect being a
larger window for stolen, revoked tokens to be used. Caching also keeps
that window open longer, so it becomes a game of tuning that window
against desired API latency.

> 
> 
> The pki token has been verified that can support such large-scale
> production environment, which even the uuid token has performance issue in
> too.
> 

As others have said, the other problems stacked on top of the critical
security problems in PKI made it very undesirable for the community to
support. There is, however, nothing preventing you from maintaining it
out of tree, though I'd hope you would instead collaborate with the
community to perhaps address those problems and come up with a "PKIv2"
provider that has the qualities you want for your scale.