On 07/29/2011 03:09 PM, Hugh Brock wrote:
1. Template design and management
(By "Template," I mean "Image templates, assembly definitions, and
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,
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
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
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
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
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
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
and wireframes, done soon. It would be really good to have a
super-simple (just system templates) implementation by the 0.4.0
All right. That was long. I'll be waiting to hear how wrong I am from
the assembled multitude. Please be thorough.