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