Aaaaaahahahahhahahahhaahhahahahahahahahahhahhahahahahhahaha On Thu, Apr 7, 2016 at 6:23 AM Lance Bragstad <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 > > wrote: > >> >> >> On Wed, Apr 6, 2016 at 6:29 PM, David Stanek <dsta...@dstanek.com> wrote: >> >>> >>> On Wed, Apr 6, 2016 at 3:26 PM Boris Pavlovic <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://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 >
__________________________________________________________________________ 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