On Fri, Jul 29, 2011 at 03:09:26PM -0400, Hugh Brock wrote:
We've had quite a bit of early user feedback asking, in no
uncertain
terms, for a nice GUI to let users define templates. We removed our
nascent template definition UI from Conductor for the 0.3.0 release
because it didn't feel right there, which I continue to think was the
right idea, but there is clearly a need for such a GUI to exist
somewhere.
+1 to this!
Fortunately, there is another project very close to Aeolus called
Katello [2]. Katello's mission in life is allowing users to define
bare-metal systems and manage their access to the software that should
be provisioned on those systems. As such, it has as a core feature
providing a UI for creating "System templates."
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.
It sounds like both of our projects have settled on their own
nomenclature here, and it's sort of confusing. I got the impression that
users already found some of the names confusing -- I tried to get them
to understand pools, pool families, templates, assemblies, deployables,
deployments, instances, images, hardware profiles, and realms, and could
see their heads spinning. Trying to throw "System templates are roughly
equivalent to assemblies, and application templates are much like
deployables" on top of that is probably too much.
(Besides the above, note that our definition of a "Template", which is
now just an XMl file, is specifically an image template, whereas now in
this email we're using "template" in its generic sense.)
I realize that we probably can't just change names all over the place,
but, as we go forward, could we work on trying to get our naming to
align between projects? I think end users would really appreciate it.
* 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.)
How does Katello know about a given user in Conductor? I somewhat assume
the answer is "OAuth," but I'm trying to figure out how this would work.
I'm mostly just hoping that we don't end up keeping separate permission
databases and requiring that admins grant users permissions in both.
Somewhere in this process a translation step between the Katello
system template and the Factory image template will need to happen. I
don't particularly care where that step is. And it's important to note
that eventually we will be passing Katello image templates to Factory,
not Katello system templates -- hacking up the system template to get
an image definition out of it is a temporary first step.
Is the end goal that we're both using the same template formats?
I also think that in general, we should not be importing the actual
template into a catalog, but rather just importing a reference to it
so that we don't have duplicate copies of templates floating
around. I'm willing to be argued out of this however.
I mostly agree with this philosophy, but I wonder if we want it to apply
to catalogs. It sounds like we want a catalog to be a "blessed" set of
templates, so I'm not sure we want to allow other people who might have
permissions on the templates to modify them.
-- Matt