On 06/01/2011 11:56 AM, Mark McLoughlin wrote:
On Tue, 2011-05-31 at 16:07 -0400, Hugh Brock wrote:
> On Tue, May 31, 2011 at 04:05:23PM -0400, Bryan Kearney wrote:
>> On 05/31/2011 03:58 PM, Pete Zaitcev wrote:
>>> On Tue, 31 May 2011 15:13:09 -0400
>>> Carl Trieloff<cctrieloff(a)redhat.com> wrote:
>>>>> Can an object have more than one group tag?
>>>> It would need to from what I understand.
>>> What's the point? A group is just an ACL that's factored out from
>>> an object so one named ACL can apply to many objects. What is it
>>> that you can accomplish having several group tags that is not possible
>>> having one group tag?
>>> The only splitter issue that I see arises when you have pre-defined
>>> groups, users that cannot create new groups, and then made do with it.
>>> They would work around it by attaching several pre-exising groups
>>> to one object.
>>> Sounds like a dumb idea. Just let users create groups as needed.
>> I am thinking of hte case where an image may belong to a group which
>> represents an environment, and another group which represetns "web
>> servers" which may cross environments.
> I may be wrong, but I believe we will provide an API for permitted
> users to tag images specifically for 0 or more environments. In other
> words I don't think we're likely to do environments with group records
> unless we think there is a really good reason to do it that way.
Right. I don't think we need to use iwhd access control mechanisms to
enforce environment policy in conductor.
Yeah, again we need to be careful to separate access control/permissions
from other policy.
Access control is just one of many policies we've got to enforce. The
only part IWHD needs to enforce is "can $user_foo launch an instance
with $image1" and "can $user_bar edit/delete/etc $image1"
Whether the user can actually launch the instance depends on a bunch of
other policies (quota usage, environment, etc). While IWHD may
facilitate the definition of these other policies (such as, for example,
storing metadata tags on each image build which defines what
environments it is intended for), IWHD isn't involved in the enforcement
there -- Conductor is choosing the provider and making the launch call
and, as such, it will make the policy decisions with regard to
environments, making use of the information it pulled from IWHD in the
form of environment metadata tags on the images.
(I did make a throwaway comment like "if we just had posix
permissions, we'd probably just use groups to represent environments".
That comment may have started this, but I don't think we have to use
Yeah, I think it gets to be way too confusing if we use groups for
anything other than "user groups" -- i.e. use groups to define groups of
users that we grant access for, but the environment itself is more of a
first-class object. It probably lives in Conductor (as what we're now
calling a PoolFamily) which maps a set of conductor pools to a set of
provider accounts, and when katello is integrated, it will probably map
one-to-one with katello environments, and IWHD will also tag image
builds with names/uuids/etc from these environments.
aeolus-devel mailing list