Open Stack

Aaaaaahahahahhahahahhaahhahahahahahahahahhahhahahahahhahaha

On Thu, Apr 7, 2016 at 6:23 AM Lance Bragstad <lbragstad at 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.fainberg at gmail.com
> > wrote:
>
>>
>>
>> On Wed, Apr 6, 2016 at 6:29 PM, David Stanek <dstanek at dstanek.com> wrote:
>>
>>>
>>> On Wed, Apr 6, 2016 at 3:26 PM Boris Pavlovic <bpavlovic at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160408/69b0359c/attachment.html>