Thank you all very much, the less data to be replicated, the better.
Best Regards
Chaoyi Huang (joehuang)
From: Clint Byrum [cl...@fewbar.com]
Sent: 26 February 2017 12:06
To: openstack-dev
Subject: Re: [openstack-dev] [keystone]PKI token VS Fernet token
Excerpts from Lance Bragstad's message of 2017-02-25 13:07:58 -0600:
> Since both token formats rebuild the authorization context at validation
> time, we can remove some revocation events that are no longer needed. This
> means we won't be storing as many revocation events on role removal from
> d
On Sat, Feb 25, 2017 at 12:47 AM, Clint Byrum wrote:
> Excerpts from joehuang's message of 2017-02-25 04:09:45 +:
> > Hello, Matt,
> >
> > Thank you for your reply, just as what you mentioned, for the slow
> changed data, aync. replication should work. My concerns is that the impact
> of repl
Excerpts from joehuang's message of 2017-02-25 04:09:45 +:
> Hello, Matt,
>
> Thank you for your reply, just as what you mentioned, for the slow changed
> data, aync. replication should work. My concerns is that the impact of
> replication delay, for example (though it's quite low chance to
On Fri, Feb 24, 2017 at 9:09 PM, joehuang wrote:
> Hello, Matt,
>
> Thank you for your reply, just as what you mentioned, for the slow changed
> data, aync. replication should work. My concerns is that the impact of
> replication delay, for example (though it's quite low chance to happen):
>
> 1)
fordable or not.
Best Regards
Chaoyi Huang (joehuang)
From: Matt Fischer [m...@mattfischer.com]
Sent: 25 February 2017 11:38
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone]PKI token VS Fernet token
At last, we
>
>
> At last, we still have one question:
> For public cloud, it is very common that multi regions are deployed. And
> the distance is usually very far between the regions. So the transport
> delay is really a problem. Fernet token requires the data must be the same.
> Because of the slow connecti
pment Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone]PKI token VS Fernet token
Thanks for all your advices and opinions.
We'll try to solve the PKI issue and hope it can come back in the future.
About the fernet token, we'll test it with the new config optio
Thanks for all your advices and opinions.
We'll try to solve the PKI issue and hope it can come back in the future.
About the fernet token, we'll test it with the new config options and show
you the result later. Hope it performs well.
At last, we still have one question:
For public cloud, it is
It appears that you don't have caching enabled, then. Without enabling
caching, Fernet performance is well known to be terrible, which would
explain your benchmark results. If you run a similar benchmark with
caching, I'd be eager to see the new configuration and benchmark results.
On Fri, Feb 17,
Ok, the advice of central database seems feasible, and we have an discuss
about it, but the delay between different region are pullback for this
advise, because it is far away between the two region. The slow sync decide
only the relatively static business can happen between the different
regions.
On Fri, Feb 17, 2017 at 11:22 AM, Clint Byrum wrote:
> Excerpts from 王玺源's message of 2017-02-17 14:08:30 +:
> > 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.
> >
>
Excerpts from 王玺源's message of 2017-02-17 14:08:30 +:
> 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
Hi Dolph:
We made the keystone.conf same with the example.
[token]
provider = fernet
[fernet_tokens] //all configuration is default
#
# From keystone
#
# Directory containing Fernet token keys. (string value)
#key_repository = /etc/keystone/fernet-keys/
# This controls how many ke
Hi Lance:
We may try cache or other setting to test fernet token in future.
Mentioned the uuid as default token, it must remind there have a big reason
to solve uuid performance issue, with the implement of pkitoken.
Openstack API using restful protocol, which built on top of Http, but these
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.
There are multiple customers have more than 6-region cascade, how to
synchronous keystone data between these region disturbed us a lot.
On Thu, Feb 16, 2017 at 5:20 PM, Dolph Mathews
wrote:
> Thank you for the data and your test scripts! As Lance and Stanek already
> alluded, Fernet performance is very sensitive to keystone's configuration.
> Can your share your keystone.conf as well?
>
> I'll also be in Atlanta and would love to
Thank you for the data and your test scripts! As Lance and Stanek already
alluded, Fernet performance is very sensitive to keystone's configuration.
Can your share your keystone.conf as well?
I'll also be in Atlanta and would love to talk Fernet performance, even if
we don't have a formal time slo
In addition to what David said, have you played around with caching in
keystone [0]? After the initial implementation of fernet landed, we
attempted to make it the default token provider. We ended up reverting the
default back to uuid because we hit several issues. Around the Liberty and
Mitaka tim
On 15-Feb 18:16, 王玺源 wrote:
> Hello everyone,
> PKI/PKIZ token has been removed from keystone in Ocata. But recently our
> production team did some test about PKI and Fernet token (With Keystone
> Mitaka). They found that in large-scale production environment, Fernet
> token's performance is not
Hello everyone,
PKI/PKIZ token has been removed from keystone in Ocata. But recently our
production team did some test about PKI and Fernet token (With Keystone
Mitaka). They found that in large-scale production environment, Fernet
token's performance is not as good as PKI. Here is the test data:
21 matches
Mail list logo