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.