On Thu, Aug 04, 2011 at 12:00:07PM +0100, Mark McLoughlin wrote:
Hey,
Wow, big thread :-)
I'm a bit behind, but a few things make sense to me so far:
Aeolus Image Templates and Katello System Templates are similar concepts, so that sounds like an obvious good place for the projects to start working together
From the Aeolus side, we'd be delighted if Katello users could build Images from System Templates, such that the Images are available for launching in Conductor
The talk of Application Templates and Deployables being similar in concept, and that Deployables might make sense on baremetal, is all very interesting. That alone is a topic worthy of much more investigation and experimentation.
There is some overlap between the Katello Environment and Conductor Pool/Pool Family concepts. ISTM that Katello is ahead of Aeolus on this one. e.g. the idea of promoting an Image Build from dev to prod is not something that we support yet.
We can choose to avoid the need for shared identity between Katello-Conductor-Factory-Warehouse by using two-legged OAuth or X.509 client certificates. However, that would mean a) not exposing Warehouse/Factory to users b) implementing a Conductor API which aeolus-image would use instead and c) making Katello enforce permissions around who can do what with images.
c) might not actually be required, if we decide (as I think we should) that images only get built within the context of a Conductor pool anyway.
The big disconnect for me is trying to understand the motivation for the Catalog concept. Some guesses:
- Perhaps we want Aeolus to consume Katello System Templates, rather the Katello build Images using Aeolus Image Templates. In that case, Conductor needs a UI to build Images from System Templates. The Catalog concept is the proposal - add a System Template to a Catalog, add the Catalog to a Pool, build the System Template for each Provider in the Pool
This first guess is pretty much what I'm after.
There are significant differences between an Aeolus image template and a Katello system template, all tied to the fact that Katello system templates are built post-boot on a running system, while Aeolus image templates are built pre-boot (and the resulting build may then be modified post-boot by assembly or deployable configuration).
Over time, I think (and I know at least some of the Katello folks agree) that it would be useful for Katello to change its model to align more closely with Aeolus image templates and Aeolus assemblies/deployables. But for now I think a good path for basic integration is to do what we have to do to use the Katello system template concept that already exists.
Why have the Catalog in between Katello and Aeolus? I addressed this in another mail a few minutes ago [1], but briefly, I think it's going to be helpful to pool admins to be able to select catalogs of apps from a list and add 1 or more of them to a pool (the fact that vCloud has this feature and it is apparently popular is part of the motivation here). The ability to group apps in Catalogs also gives pool admins a fairly easy way to separate dev apps from prod apps (for example).
Perhaps this is the way to allow promoting groups of Images or Deployables from dev to prod. If so, why not just implement that for individual Images or Deployables, first?
Perhaps this is a way to go back to the idea of launching Templates rather than launching Images?
Honestly, I'm really struggling. It feels like another level of indirection, and that's not what Conductor needs right now.
Other thoughts:
- In all this, we don't seem to be making any distinction between user stories for admins and self-service users. Is design targeted at admins building images using Katello and making them available to self-service Conductor users? Or do we expect Conductor's self-service users to build images themselves using Katello?
Good point. I don't think I've made clear yet that I think it should be possible for an admin to configure a pool such that a self-service user can load up a deployable descriptor and launch it, just as they do in 0.3.0 today. In that case the self-service user owns the responsibility of building his own images.
However I think it should also be possible for an admin to configure a pool such that the ability and responsibility to build images for the pool is restricted to pool admins. In that case, all the self-service user is allowed to do is launch apps that are already in a catalog mapped to the pool.
- I like the idea of Katello building images and making them available to Conductor. I'm not sure why we'd flip that around and have Conductor pull System Templates from Katello.
Really, it's expediency. Katello's not going to be ready to grow UI to do this, in the short term at least, while we are. Plus if Katello is building images, it has to know what pool they're going in -- which is perfectly doable, but we might want to put it off for now.
- If we make Katello talk directly to Conductor for image building, then Conductor takes on the role of image building service. That strikes me as very strange. I think it still makes sense for Katello to talk directly to Factory and Warehouse, even without sharing identity with them.
Again, see the pool thing...
- I really wish we weren't discussing this as a "what can we do in 3 months?", as I think we're tending to overreach. If we were planning for a release in 3 weeks, it would focus the minds more.
It's a fair point. What's driving this discussion for me is the need to tell the Warehouse guys very soon whether or not we need them to implement identity checking and permission checking, because that's going to take them a while. I think this catalog stuff eliminates the need to do that, so that's why I've taken it this far. Of course, what's good for Warehouse is Jim and Pete's responsibility to figure out, but if we can tell them whether we need auth and authz, it will be helpful.
Take care, --H
[1] https://fedorahosted.org/pipermail/aeolus-devel/2011-August/003868.html