On Thu, Feb 16, 2017 at 5:20 PM, Dolph Mathews <dolph.math...@gmail.com> 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 talk Fernet performance, even if > we don't have a formal time slot on the schedule. > ++ Our schedule is coming together and this is what we have so far [0]. If there is an open time slot that works for your schedule, don't hesitate to let me know. [0] https://etherpad.openstack.org/p/keystone-pike-ptg > > On Wed, Feb 15, 2017 at 9:08 AM Lance Bragstad <lbrags...@gmail.com> > wrote: > >> 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 timeframe, we reworked the caching implementation to fix those >> issues and improve overall performance of all token formats, especially >> fernet. >> >> We have a few different performance perspectives available, too. Some >> were run nearly 2 years ago [1] and some are run today [2]. Since the >> Newton release, we've made drastic improvements to the overall structure of >> the token provider [3] [4] [5]. At the very least, it should make >> understanding keystone's approach to tokens easier. Maintaining out-of-tree >> token providers should also be easier since we cleaned up a lot of the >> interfaces that affect developers maintaining their own providers. >> >> We can try and set something up at the PTG. We are getting pretty tight >> for time slots, but I'm sure we can find some time to work through the >> issues you're seeing (also, feel free to hop into #openstack-keystone on >> freenode if you want to visit prior to the PTG). >> >> >> [0] https://docs.openstack.org/developer/keystone/ >> configuration.html#caching-layer >> [1] http://dolphm.com/benchmarking-openstack-keystone-token-formats/ >> [2] https://github.com/lbragstad/keystone-performance >> [3] https://review.openstack.org/#/q/status:merged+project: >> openstack/keystone+branch:master+topic:make-fernet-default >> [4] https://review.openstack.org/#/q/status:merged+project: >> openstack/keystone+branch:master+topic:cleanup-token-provider >> [5] http://specs.openstack.org/openstack/keystone-specs/ >> specs/keystone/ocata/token-provider-cleanup.html >> >> On Wed, Feb 15, 2017 at 8:44 AM, David Stanek <dsta...@dstanek.com> >> wrote: >> >> 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 as good as PKI. Here is the test data: >> > >> > https://docs.google.com/document/d/12cL9bq9EARjZw9IS3YxVmYsGfdauM >> 25NzZcdzPE0fvY/edit?usp=sharing >> >> This is nice to see. Thanks. >> >> >> > >> > From the data, we can see that: >> > 1. In large-scale concurrency test, PKI is much faster than Fernet. >> > 2. PKI token revoke can't immediately make the token invalid. So it has >> the >> > revoke issue. https://wiki.openstack.org/wiki/OSSN/OSSN-0062 >> > >> > But in our production team's opinion, the revoke issue is a small >> problem, >> > and can be avoided by some periphery ways. (More detail solution could >> be >> > explained by them in the follow email). >> > They think that the performance issue is the most important thing. Maybe >> > you can see that in some production environment, performance is the >> first >> > thing to be considered. >> >> I'd like to hear solutions to this if you have already come up with >> them. This issue, however, isn't the only one that led us to remove PKI >> tokens. >> >> > >> > So here I'd like to ask you, especially the keystone experts: >> > 1. Is there any chance to bring PKI/PKIZ back to Keystone? >> >> I would guess that, at least in the immediate future, we would not want >> to put it back into keystone until someone can fix the issues. Also >> ideally running the token provider in production. >> >> >> > 2. Has Fernet token improved the performance during these releases? Or >> any >> > road map so that we can make sure Fernet is better than PKI in all side. >> > Otherwise, I don't think that remove PKI in Ocata is the right way. Or >> > even, we can keep the PKI token in Keystone for more one or two cycles, >> > then remove it once Fernet is stable enough. >> > 3. Since I'll be in Atalanta next week, if it is possible, I'd like to >> > bring this topic to Keystone PTG. can I? >> >> Sure. We have a pretty packed calendar, but I'm sure you could steal a >> few minutes somewhere. >> >> >> > >> > It is a real production problem and I really need your feedback. >> > >> >> Have you tried playing with the crypt_strength[1]? If the slowness is >> the crypto (which it was in the past) then you can tune it a little bit. >> Another option might be to keep the same token flow and find a faster >> method for hashing a token. >> >> 1. http://git.openstack.org/cgit/openstack/keystone/tree/etc/ >> keystone.conf.sample#n67 >> >> >> -- >> david stanek >> web: https://dstanek.com >> twitter: https://twitter.com/dstanek >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: >> unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: >> unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > -- > -Dolph > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
