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.
[snip]
[snip]
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 useful.)
Let me know if you think this makes sense.
--Hugh
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 level.
We need to get to it from user side. A user story for a pool user would be helpful.
Ahh, I see where you're going. I believe I can answer these questions quickly.
* 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?
Thanks, --Hugh