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.
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
- 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?
- 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.
- 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.
- 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.
Cheers,
Mark.