You know it’s an interesting discussion thread on keystone when both Termie and 
I are watching, chuckling, and grimacing in remembered pain …

-joe

From: Andy Smith <andys...@gmail.com<mailto:andys...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Friday, April 8, 2016 at 9:12 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [tc][ptl][keystone] Proposal to split 
authentication part out of Keystone to separated project

Aaaaaahahahahhahahahhaahhahahahahahahahahhahhahahahahhahaha

On Thu, Apr 7, 2016 at 6:23 AM Lance Bragstad 
<lbrags...@gmail.com<mailto:lbrags...@gmail.com>> wrote:
In response to point 2.2, the progress with Fernet in the last year has exposed 
performance pain points in keystone. Finding sensible solutions for those 
issues is crucial in order for people to adopt Fernet. In Mitaka we had a lot 
of discussion that resulted in landing several performance related patches.

As of today, we're already focusing on scalability, performance, and 
simplicity. I'm afraid a project split would only delay the work we're doing 
right now.

On Wed, Apr 6, 2016 at 5:34 PM, Morgan Fainberg 
<morgan.fainb...@gmail.com<mailto:morgan.fainb...@gmail.com>> wrote:


On Wed, Apr 6, 2016 at 6:29 PM, David Stanek 
<dsta...@dstanek.com<mailto:dsta...@dstanek.com>> wrote:

On Wed, Apr 6, 2016 at 3:26 PM Boris Pavlovic 
<bpavlo...@mirantis.com<mailto:bpavlo...@mirantis.com>> wrote:

2) This will reduce scope of Keystone, which means 2 things
2.1) Smaller code base that has less issues and is simpler for testing
2.2) Keystone team would be able to concentrate more on fixing perf/scalability 
issues of authorization, which is crucial at the moment for large clouds.

I'm not sure that this is entirely true. If we truly just split up the project, 
meaning we don't remove functionality, then we'd have the same number of bugs 
and work. It would just be split across two projects.

I think the current momentum to get out of the authn business is still our best 
bet. As Steve mentioned this is ongoing work.

-- David


What everyone else said... but add in the need then to either pass the AuthN 
over to the Assignment/AuthZ api or bake it in (via apache module?) and we are 
basically where we are now.

Steve alluded to splitting out the authentication bit (but not to a new 
service), the idea there is to make it so AuthN is not part of the CRUD 
interface of the server. All being said, AuthN and AuthZ are going to be hard 
to split into two separate services and with exception of the unfounded "scope" 
benefit, we already can handle most of what you've proposed with zero changes 
to Keystone.

Cheers,
--Morgan


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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://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

Reply via email to