On 08/04/2011 03:10 PM, Hugh Brock wrote:
On Thu, Aug 04, 2011 at 03:02:19PM -0400, Hugh Brock wrote:
> 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]
>> 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.
Meh. This wasn't as clear as I meant. What I meant to say was that the
permission to start an app in a pool is on the pool-user tuple. If a
catalog is mapped to a pool, any user in that pool with start
permission can start any app in the mapped catalog. Hopefully that is
marginally clearer.
I am fine with this definition it makes technical sense though I am not
sure it is the right and meaningful definition of the catalog from end
user POW. Is this really what Andy wants or this is what we plan to
give? What I am struggling with is that in this case catalog does not
model any real life concept. It seems artificial and a bit useless. I
suspect that the whole idea of the catalog comes form some real life use
cases that are modeled well by having a catalog of images to pick from.
However is seems that we are trying to squeeze it into the existing
model of pools/environments/images/templates/deployables without much
success. We might be squeezing it into the wrong place in our model...
So let me try to speculate (I might be totally wrong):
What is catalog to me? It is a magazine that I get in mail that I can
use to order things I want to buy. OK what else? Hm it is a structured
list of the inventory that I can pick from that allow me to easily find
what I need. Do I have multiple catalogs per vendor? No. Do I have
multiple catalogs that sell similar things? Hm... yes in case of
magazines but in an online store multiple vendors come from one catalog...
Ok so back to the catalog in cloud forms. Why does user need a catalog?
Is it because there will be a huge inventory of the applications and the
user needs to have a quick way to find the app he needs? Or the catalog
is really more a cookbook meaning that it contains only things that are
relevant to my line of business as user. There might be other reasons
that I do not know of.
But neither of the two reasons above map well to what we plan to
provide. This is kind a problem I see. Are we doing the right thing? I
am not saying that we do not need a "catalog" I think we should but it
should have a different meaning and land into a different place in the
model from what is currently proposed.
Not trying to derail the current plan but rather trying to avoid a
useless work.
--H
> 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
>
> --
> == Hugh Brock, hbrock(a)redhat.com ==
> == Engineering Manager, Cloud BU ==
> == Aeolus Project: Manage virtual infrastructure across clouds. ==
> ==
http://aeolusproject.org ==
>
> "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."
> --Robert McCloskey
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/