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@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