[openstack-dev] [openstack-common]Add support for finer-grained policy decisions

Adam Young ayoung at redhat.com
Wed Oct 10 19:56:07 UTC 2012


On 10/10/2012 02:54 PM, heckj wrote:
> Actually - to that end, I'll see if I can arrange a meeting during the summit to try and capture this together or at least get a start on writing this down and getting the word out that we're looking for feedback and use cases.

Might I suggest  the 11 AM  unconference ON Wednesday?  I'd like to attend.



>
> -joe
>
> On Oct 10, 2012, at 11:53 AM, heckj <heckj at mac.com> wrote:
>> On Oct 10, 2012, at 11:30 AM, Kevin L. Mitchell <kevin.mitchell at rackspace.com> wrote:
>>>> I would, however, very much like to see a suggestion of roles and
>>>> associated policies that do what Kevin needs as a suggestion for
>>>> deployment. Kevin - how far down the road are you with roles and
>>>> definitions for those roles of what you're doing? I'd love to get the
>>>> layout to document it and include it, along with the current highly
>>>> simplified global-role and come up with some structures that we can
>>>> make available for suggesting how to configure openstack roles and
>>>> policy files that would be useful for a wide variety of use cases.
>>> Honestly, I'm not certain I understand what you're asking here.  I came
>>> up with the "case" mechanism due to a half-remembering of how the user
>>> quotas patch worked, and I figured that could be addressed effectively
>>> that way; I also figured someone might find that functionality useful.
>>> I didn't have specific roles or associated policies in mind.
>> Not surprisingly, Vish said it much better than I did. I really want to look at the roles from the operator's perspective and nail down what needs to get done, and then compare that to what can be done with what we have today and then focus on working to close that gap.
>>
>> Vish' outline is a much better articulation of what I was trying to say:
>>
>> a) making sure the policies are named in a consistent manner
>> b) grouping the policies in a way that makes them easy to edit for operators.
>> In other words, I think in most cases there are only a few policies that will be
>> touched, so make configuring those easy
>> c) standard definitions of which things should be policy controlled and ensuring
>> that all of those are in place.
>> d) documentation on configuring policies
>>
>> -joe
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list