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
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.
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
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
there may be additional images I can see in that environment.
(This sounds to me like a policy managed by the image tools and
enforced by Conductor)
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
entitlement. 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.