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.
>> Hm I think I understand what you are talking about but that leads back
>> to the definition of the catalog and its purpose. If the purpose of the
>> catalog is to have a collection of usable deployables that a group of
>> people can launch in a pool then it seems that there should be a
>> workflow related to "publishing" something to a catalog.
>> I assume that the catalog relation to pool or pools should probably
>> established first before anything is published to a catalog. Then the
>> act of publishing is the point when the transformation from the
>> templates to images occur. In other words:
>> * Templates are associated with the catalog
>> * Images are built for the specific pools
>> * Right permissions derived from the catalog access are set on the
>> images if images can be accessed outside Conductor. Otherwise the images
>> do not need to have any permissions as the permissions can be defined on
>> a per catalog basis.
>> Makes sense?
> After some more thinking I nailed down the issue that was bothering me.
> What is still not clear and not defined is the logical meaning of the
> catalog. We have the technical meaning but not the logical. What is a
> catalog for an end user? Is it a group of applications he and his team
> can run in a specific environment? For example HR team can run HR
> applications while Finance can run finance applications? One has HR
> catalog to pick from and another Finance catalog to pick from. In this
> case the access to the catalog means at least access to see and probably
> launch applications. The model might allow (or not allow) Individual
> people to have more granular permissions regarding editing of the images
> in the catalog (unclear).
> May be catalog has other meaning to the end users and it is more
> pool/provider oriented. May be it is something else. The point is that
> without defining the purpose of the catalog we would not be able to
> define right permissions and workflows around it. May be I missed that
> part. Sorry. But I do not remember that being clearly spelled out.
> 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
Sr. Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?