On Thu, Aug 04, 2011 at 01:18:28PM -0400, Dmitri Pal wrote:
On 08/04/2011 08:25 AM, Hugh Brock wrote:
> On Wed, Aug 03, 2011 at 10:04:28PM -0400, Dmitri Pal wrote:
>> On 08/03/2011 07:27 PM, Dmitri Pal wrote:
>>> On 08/03/2011 10:34 AM, Hugh Brock wrote:
>>>> On Tue, Aug 02, 2011 at 08:13:55PM -0400, Dmitri Pal wrote:
>>>>> On 08/02/2011 07:07 AM, Hugh Brock wrote:
>>>>>> The first mail in the thread has a pretty good description of
what catalogs are and what features they need to have for this iteration.
>> I hope my questions help to clarify how things are going to work together.
> Good questions Dmitri. Some of this should really go back to Andy
> Smith, who had this idea in the first place, but I will attempt to
> proxy for him here.
> I see two roles, maybe three, that are interesting for Catalogs:
> * Catalog admin. Can create catalogs, add/remove applications from
> them, grant/revoke access to them. Cannot add catalogs to pools or
> remove from pools.
> * Pool admin (in practice probably the same person). Can add/remove
> catalogs from pools, manage building/rebuilding images referenced by
> apps in catalogs. Cannot create/edit catalogs.
> * Pool user. Can see apps in catalogs that are mapped to pools,
> start/stop those apps. Cannot manage pools or catalogs, or do
> anything with images that are referenced by catalogs.
> I've split these roles up this way to facilitate catalogs being
> mappable to more than one pool, which we think is important simply
> because we think admins will want to be able to re-use catalogs. (I
> will also say that the first time I talked about this with Andy I
> tried to talk him out of this idea -- i.e. just add apps directly to
> pools -- but he convinced me that catalog portability was in fact
> Let me know if you think this makes sense.
This makes sense but this does not answer the question.
With the explanation above the question I asked transforms into:
What are the examples of "Pool users"? What function in the organization
such user is mapped to? Also do pool users have same rights against all
apps in the catalog? If so that means that the permissions are on the
catalog level. If the users have different access rights against same
catalog (i.e. two pool users say HR have access to different apps in the
same catalog) the access control is more on the per app/template/image
We need to get to it from user side. A user story for a pool user would
Ahh, I see where you're going. I believe I can answer these questions
* All pool users who have the right to start/stop any app in any
catalog mapped to a pool, have the right to start/stop all apps in
all catalogs mapped to that pool, but *only* in that pool.
So if I have permission to start apps in the aeolus-staging pool, and
the administrator for the aeolus-staging pool adds a catalog to that
pool (and note he must have permission on both the catalog and the
pool to do so), then I can start any of the apps in that catalog in
the aeolus-staging pool.
I believe this is enough constraint, at least for iteration 4. Agree?
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."