On Fri, Jul 29, 2011 at 03:09:26PM -0400, Hugh Brock wrote:
Hello all.
We've had a lot of good discussion on the Aeolus list [1] about authorization and identity lately, and also about the intersection points of Aeolus and Katello. However I have been slow (sorry!) to suggest and update the requirements and user stories for this integration, and that has left folks asking a lot of questions about the features that are affected by that integration, in particular:
We will eventually need a UI for creating and managing templates, assemblies, and deployables -- where's that gonna go?
Precisely which components have to talk to each other securely in a system where Katello and Conductor work together?
Is there a need for an independent permission system in the Warehouse? What about an independent identity system?
One of the very cool features VCloud has is the ability to take a bunch of applications -- really, VM templates -- and put them in a "Catalog" that an admin can grant or revoke permission on for a set of users. The virtue of the catalog is that it gives admins an easy way to manage, say, "all the financial apps that are approved for production," or "the apps that are in testing this week." We need something like this for Aeolus, but how does it work exactly, and which part of the system owns it?
I've been in a lot of meetings this week where we talked about these questions, so I'm going to propose some answers here based on that. There are a ton of unanswered questions as well, and I'm hopeful that Aeolus and Katello folks can help answer them here.
(Katello folks, apologies for dumping a mostly-aeolus-centered design doc into your midst, but I thought you guys might want to know what we're thinking about too. Please feel free to comment on either or both lists.)
[big snip here]
- Catalogs
===========
Although my first thought about catalogs as a feature was "I guess we're doing this just because VMWare has them and we need to check the feature complete box," the more we talked about the feature the more I began to see it as a useful thing.
Things administrators can do with catalogs:
For now, group image templates into a catalog; eventually, group application templates into a catalog
Connect catalogs to pools, making it possible for users to run the applications in the catalog
Check that the images that the applications in a catalog depend on, have been built for the cloud provider accounts connected to a pool, so that it is possible to launch the applications.
Disconnect catalogs from pools. Maybe, also remove images that are no longer referenced by an application that is connected to a pool.
So from a user story perspective, you can imagine that an administrator, on creating or maintaining a pool, would be able to browse catalogs of applications to add to that pool. On adding the catalog to the pool, the admin would be able to check to make sure the images required by the apps in that catalog are built for all the provider accounts the pool has access to. The users of that pool would gain the ability to launch the listed applications.
I would like to see the design activity for catalogs, and hopefully UX and wireframes, done soon. It would be really good to have a super-simple (just system templates) implementation by the 0.4.0 release.
OK, I already forgot something: You shouldn't *have* to use catalogs if you don't want to. Catalogs are really mostly helpful for the self-service case, where an admin wants to set things up in advance so that users are constrained to a set of applications they can run. We should also support a case where a user can be given permission (and interfaces) to run anything they want in a pool.
--Hugh