[openstack-dev] [Openstack-operators] [keystone] RBAC usage at production

Steve Martinelli stevemar at ca.ibm.com
Wed Dec 9 22:20:48 UTC 2015


Whether or not a restart is required is actually handled by oslo.policy.
Which is only included in Kilo and newer versions of Keystone. The work to
avoid restarting the service went in in commit [0] and was further worked
on in [1].

Juno and older versions are using the oslo-incubator code to handle policy
(before it was turned into it's own library), and AFAICT don't have the
check to see if policy.json has been modified.

[0]
https://github.com/openstack/oslo.policy/commit/63d699aff89969fdfc584ce875a23ba0a90e5b51
[1]
https://github.com/openstack/oslo.policy/commit/b5f07dfe4cd4a5d12c7fecbc3954694d934de642

Thanks,

Steve Martinelli
OpenStack Keystone Project Team Lead



From:	Timothy Symanczyk <Timothy_Symanczyk at symantec.com>
To:	"OpenStack Development Mailing List (not for usage questions)"
            <openstack-dev at lists.openstack.org>, "Kris G. Lindgren"
            <klindgren at godaddy.com>, Oguz Yarimtepe
            <oguzyarimtepe at gmail.com>,
            "openstack-operators at lists.openstack.org"
            <openstack-operators at lists.openstack.org>
Date:	2015/12/09 04:40 PM
Subject:	Re: [openstack-dev] [Openstack-operators] [keystone] RBAC usage
            at production



We are running keystone kilo in production, and I¹m actively implementing
RBAC right now. I¹m certain that, at least with the version of keystone
we¹re running, a restart is NOT required when the policy file is modified.

Tim




On 12/9/15, 9:18 AM, "Edgar Magana" <edgar.magana at workday.com> wrote:

>We use RBAC in production but basically modify networking operations and
>some compute ones. In our case we don¹t need to restart the services if
>we modify the policy.json file. I am surprise that keystone is not
>following the same process.
>
>Edgar
>
>
>
>
>On 12/9/15, 9:06 AM, "Kris G. Lindgren" <klindgren at godaddy.com> wrote:
>
>>In other projects the policy.json file is read each time of api request.
>> So changes to the file take place immediately.  I was 90% sure keystone
>>was the same way?
>>
>>___________________________________________________________________
>>Kris Lindgren
>>Senior Linux Systems Engineer
>>GoDaddy
>>
>>
>>
>>
>>
>>
>>
>>On 12/9/15, 1:39 AM, "Oguz Yarimtepe" <oguzyarimtepe at gmail.com> wrote:
>>
>>>Hi,
>>>
>>>I am wondering whether there are people using RBAC at production. The
>>>policy.json file has a structure that requires restart of the service
>>>each time you edit the file. Is there and on the fly solution or tips
>>>about it?
>>>
>>>
>>>
>>>_______________________________________________
>>>OpenStack-operators mailing list
>>>OpenStack-operators at lists.openstack.org
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>_______________________________________________
>>OpenStack-operators mailing list
>>OpenStack-operators at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>__________________________________________________________________________
>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/20151209/848a5509/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151209/848a5509/attachment.gif>


More information about the OpenStack-dev mailing list