On Thu, Aug 04, 2011 at 12:00:07PM +0100, Mark McLoughlin wrote:
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
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 , 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
- 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.
- 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
== Hugh Brock, hbrock(a)redhat.com ==
== Engineering Manager, Cloud BU ==
== Aeolus Project: Manage virtual infrastructure across clouds. ==
"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."