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.