On Thu, 2011-08-04 at 09:15 -0400, Hugh Brock wrote:
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.
Okay, that's fine. I'm not sure how that influences whether Katello or Conductor should build images, though.
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).
See, you can't add individual apps to a pool or promote them from prod to dev etc. So, talking about doing that for groups of apps seems premature to me. Also, I don't see why we should conflate it with Katello integration.
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.
Okay, as always, the answer is "both - it's just a question of permissions" :-)
- 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.
That doesn't seem like a great reason to me. You want Conductor to become an image builder again because Conductor is stuck for feature work? And we can't just help Katello?
Before making this drastic call, I'd wait until we've at least prototyped building images from Katello system templates.
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.
We have no concept in Conductor right now of associating images with pools. How about we add that first?
- 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.
We said a few weeks ago that we do need it. We might decide now that we don't, but I wouldn't discount the possibility of us changing our minds again soon :-)
The big question for me is whether we want Conductor to have an image building and listing API. If it does, then we can hide factory and warehouse behind it. If it doesn't, the image factory and warehouse APIs need to be exposed directly.
One detail suggests that we do need such an API - right now, in order for a user to push an image using aeolus-image, she needs to have permissions to the provider account credentials. That probably doesn't make sense. To fix it, aeolus-image would need Conductor to send the push request to factory on its behalf.
The starting point for such an API would be the current the aeolus-image codebase.
Cheers, Mark.