On 01/08/11 20:28, Hugh Brock wrote:
On Mon, Aug 01, 2011 at 09:48:20AM -0400, Bryan Kearney wrote:
On 07/29/2011 03:09 PM, Hugh Brock wrote:
Of course, it will be some time before the Katello folks can design and build the whole UI for managing all three kinds of Aeolus templates and their interactions and dependencies. However, we don't have to wait for that to happen before we can start thinking about making Conductor and Katello work together. For release 0.4.0, I would think we could get by with the following features:
Katello provides an API that, given a user Katello knows about, will return all the Katello system templates that user has permission to see. (Note that templates in Katello are grouped by "environment," and that a user can have permission on more than one environment, so we'll have to deal with that hierarchy in the API somehow.)
The Aeolus team builds a UI piece in or next to Conductor will allow the user to:
map those templates to a catalog (more about this later)
map non-Katello templates (assemblies/deployables) to a catalog. For now this could be pretty much the same mechanism that our "Suggested Deployable" UI uses now -- store a URL of a deployable to use
Another UI piece, in or next to Conductor, will allow a user to:
map a catalog to a pool
check to see if the templates in that catalog have been built into images that have been pushed to the cloud provider accounts that the pool has access to
ask the Image Factory to build and push any templates that have *not* been built in the available accounts
display the status of the build(s)
Hugh... can you map out 2 stories and a proposed set of api calls? I am thinking the following:
- As a user, I build a template and would like to have it launched
in the cloud.
Sure, yeah, good idea. Here's one:
Story 1: As a user, I define a template and would like to launch it in the cloud (subtle change of "build" to "define" here is important)
- Install Katello
- Install Aeolus and configure it so it knows how to reach Katello
- Configure Katello so it knows how to reach Aeolus
- In the Katello UI, choose an org and an environment to work in
- In the Katello UI, define a system template (please update this as
required to reflect my imperfect knowledge of Katello). 6. (OPTIONAL) In the Katello UI, choose a Conductor catalog to add the template to
- OR -
- (OPTIONAL) In the Katello UI, choose an Conductor pool to launch in
(bypass catalog manipulation altogether) 7. Behind the scenes, template is built into an image, pushed, and launched. 8. In the Katello UI, see a link to the Aeolus pool the image is running in
Shouldn't there be a switch over the the Conductor UI before an instance is launched? There are a few things which might need to be done before launching:
- selecting a hardware profile - selecting a realm - defining any launch-time parameters associated with the image
Unless we stick with an approach where all types of templates are defined in Katello, and then launched via Conductor, we'll need to add management of those launch time actions into the Katello UI.
THINGS TO NOTE ABOUT THIS STORY:
- For now, I've ignored deployables, since Katello isn't going to
know anything about them this iteration. In practice, when Katello adds a template to a catalog or builds/launches it in a pool, we'll probably wrap it in empty assembly/deployable structures. Once Katello is able to manage and launch application templates (deployables), we can move the UI that lets Katello users add to catalogs or launch over to the application template section, or something like that.
- Somewhere in the chain here, something is going to have to take the
available Katello system template, which specifies a base OS, some packages, and (eventually) some configuration, and make it into instructions that the image factory can understand. Seems to me that translator piece probably belongs in the catalog manager or somewhere in the vicinity of Conductor, although I could be wrong about that.
APIs implied by this story:
Conductor provides API that will let a user read the catalogs and pools he has permission to see
Conductor provides API that will let a user add a deployable or application to a catalog
Conductor provides API that will let a permitted user launch a deployable, independently of catalogs
Conductor (may) provide a capability that will check if a deployable needs images built and go build them and push them before launch
- As a user, I am building out a catalog and launch it.
Story 2: As a user, I want to add templates to a catalog, map that catalog to a pool, and launch an entry in the catalog.
- Assume a Katello already installed, with some available templates
- Install Aeolus, tell it how to reach Katello
- In the catalog management UI, choose "Add an application." UI lists
Katello orgs/environments the user can see. 4. In the catalog management UI, choose an environment. UI lists the templates the user can see in that environment. Choose a template to add to the catalog 5. In the catalog management UI, see a list of pools the catalog is mapped to. Choose one 6. In the pool UI, choose the new template, see option to build template for all the cloud back ends in the pool, choose that option 7. Conductor (via factory) builds images from template 8. In the pool UI, launch the new template.
APIs implied by this story:
Katello provides API that will let a user read the templates available to build/launch to launch
OK, this is a lot to consume, so I'm going to stop. Does it make sense to everyone?
--Hugh