On 07/29/2011 03:09 PM, Hugh Brock wrote:
Hello all.
- Template design and management
=================================
(By "Template," I mean "Image templates, assembly definitions, and deployable definitions")
Hmm -- can we generalize all of these into the same term? With the latest redesign, Templates and Assemblies/deployables seem to be at rather different levels now.
The Image Template is uses as an input to the image building process. So the template will live in Katello, and the Images (and related sub-objects Build, Provider Image, etc) will live in IWHD.
Now the assemblies and deployables reference the Images, not the Templates (unless that will change as part of the katello integration), so it's a bit unclear to me how we can reference both Templates and Deployables as if they were equivalent.
I believe, and I think the Katello folks agree, that Katello users would benefit from being able to use it to define systems that will run in the cloud, as well as bare-metal systems. From there it's not a big leap to say that Katello users will want to define the entire range of templates that Aeolus can use and understand -- image templates, for stuff that gets built pre-boot; system templates (Katello) or assemblies (Audrey), for stuff that happens to a system post-boot; and application templates (Katello) or deployables (Audrey) for hooking systems together post-boot.
Note that the last of these things -- application templates -- are also really useful for the bare-metal world. Given a set of system templates, and the ability to specify a set of systems that work together, it's not a big stretch to think that Katello users will want a way to provision and launch that set of systems -- an application -- either on a set of bare-metal machines, *or* in a cloud provided by Conductor.
Of course, it will be some time before the Katello folks can design and build the whole UI for managing all three kinds of Aeolus templates and their interactions and dependencies. However, we don't have to wait for that to happen before we can start thinking about making Conductor and Katello work together. For release 0.4.0, I would think we could get by with the following features:
Referring back to my prior comments, it looks like you're suggesting that we take a step back from our last redesign and go back to defining assemblies/deployables in terms of templates rather than images -- I'm not sure how that will work with the aeolous-image and conductor side, though. Do we need a "translation" component that will take a template-centric deployable and convert it into an image-centric one?
Katello provides an API that, given a user Katello knows about, will return all the Katello system templates that user has permission to see. (Note that templates in Katello are grouped by "environment," and that a user can have permission on more than one environment, so we'll have to deal with that hierarchy in the API somehow.)
The Aeolus team builds a UI piece in or next to Conductor will allow the user to:
map those templates to a catalog (more about this later)
map non-Katello templates (assemblies/deployables) to a catalog. For now this could be pretty much the same mechanism that our "Suggested Deployable" UI uses now -- store a URL of a deployable to use
But unlike the current suggested deployable model, it sounds like we'd change the 'launch' UI to mandate coming via this path (depending on permissions)
...
- 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
If the long-term plan will be to only have deployables in a catalog (i.e. "things users might launch" in the catalog), might it make more sense to have some mechanism for auto-generating a deployable from katello image templates (sort of what we're proposing already for conductor UI 'launch from an image'), but with one more step -- we'd have to build the image first so we'd have an image ID to stuff into the deployable.
I think image templates are too far removed from launching at this point for it to make too much sense having them in catalogs, unless catalog membership is also needed long-term for templates. Catalog membership for templates, though, would mostly be needed as an input to the deployable-generation process -- i.e. should template-catalog associations constrain the sort of deployables that are created?
- Connect catalogs to pools, making it possible for users to run the applications in the catalog
So this catalog-pool model would be completely on the conductor side I'd imagine? The catalogs themselves (along with katello-maintained deployables, templates, etc contained in the catalos) would be pulled from Katello via an ActiveResource model like we'll be doing for IWHD.
- 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.
So the provider accounts belong to the environment (once we rename pool family to 'environment'), but the pools belong to those, so we do have this relationship indirectly.
- 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.
So is the pool the right place to attach catalogs, or is environment/pool family the right place?
Also, to alleviate a bit of confusion on permissions here, it's not stated here explicitly, but I think you had said this on IRC that once we link deployables to catalogs (and catalogs to pools and/or environments) we'd want to create two levels of user permissions here: 1) some users will be able to launch a deployment in a pool, limited to choose only deployments that belong to catalogs attached to the pool/environment 2) other users will be able to launch any deployment in the pool -- i.e. they could choose deployments defined in catalogs _not_ linked to this pool, or they could launch deployments not referenced by katello at all -- by directly providing the deployable xml that references images in iwhd.
Is the above correct as well?
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.
All right. That was long. I'll be waiting to hear how wrong I am from the assembled multitude. Please be thorough.
Thanks, --Hugh
[1] aeolus-devel@fedorahosted.org [2] http://katello.org