On 05/27/2011 11:48 AM, Mark McLoughlin wrote:
On Thu, 2011-05-26 at 14:02 -0400, Carl Trieloff wrote:
> On 05/26/2011 10:57 AM, Mark McLoughlin wrote:
>> We had a chat earlier medium term plans for image permissions. John is
>> going to write up some more detailed design thoughts, but I thought I'd
>> write down my understanding of the basic requirements before I forget:
>> 1) Access control
>> We need users to be able to restrict access to images they create
>> or own - e.g. if you've got sensitive data in an image, or you
>> just want to prevent others from being able to delete your images
>> (This sounds to me like posix filesystem style permissions on
>> IWHD objects)
>> 2) Quotas
>> When an administrator adds a provider account in conductor, she
>> needs to be able to set a per-user quota for that account
> correct for iwhd.
I don't understand what you mean by that.
>> - e.g.
>> Mary can only use 20Gb of S3 storage on this EC2 account
> no, we don't control the ec2 quota, we control the iwhd quota
Poorly phrased. Better attempt is ""Mary can only user 20 GB of storage
on this provider account for image storage"
> then, more specifically, when a user is added, by admin or by
> self-service, default quota and permissions need to be given to the user.
>> (This sounds to me like a policy stored in Conductor, enforced
>> either by conductor or image factory. If the latter, the quota
>> could be passed to image factory via the credentials XML)
>> 3) Environment/pool family policies
>> Based on the environment a user is launching an instance, a
>> different set of images should be available to the user.
> I would not state it this way, rather
> Based on an environment, I may have a different set of permissions. In
> addition there may be additional images I can see in that environment.
The only time I see environment coming into this from a user's
perspective is when they are launching a deployable - i.e. they are
launching a deployable in an environment
And the only permission that seems relevant when launching a deployable
is whether a given image is available to that user for that environment
So, I'd prefer the less generic version .... or multiple less generic
statements that make it more obvious what policy is being enforced.
Here is the use-case, This item comes down to delectation.
I upload an image, I have permission to 'move' it into prod, and allow
anyone in prod to
launch it, but not delete it.
>> (This sounds to me like a policy managed by the image
>> enforced by Conductor)
>> 4) Entitlements/slots
>> This I'm less clear on. Take RHEL entitlements. When a RHEL
>> instance is started, it should automatically consume an
>> entitlement. However, does an image consume an entitlement? If so,
>> how do we make that happen?
> images do NOT consume an entitlement, only running images consume
> We may also want to consume an entitlement for the latest
> rev only of a image tree, if no instance is running, but that is TBD.
> theory that a 'managed' image is an entitlement.
So, "every build, target image and provider will not consume an
entitlement, but an image may consume one"
We should not consume an entitlement to build an image, and in v1 I believe
we can assume that we will only consume an entitlement when we launch.