On Tue, Aug 02, 2011 at 08:48:13AM -0400, Todd Sanders wrote:
On 08/01/2011 05:07 PM, Hugh Brock wrote:
>On Mon, Aug 01, 2011 at 04:53:31PM -0400, Todd Sanders wrote:
>>On 08/01/2011 03:28 PM, 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
>>>>>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
>>>>>think we could get by with the following features:
>>>>>* Katello provides an API that, given a user Katello knows about,
>>>>> return all the Katello system templates that user has permission
>>>>> see. (Note that templates in Katello are grouped by
>>>>> 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
>>>>> 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
>>>>> our "Suggested Deployable" UI uses now -- store a URL
>>>>> 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
>>>>> images that have been pushed to the cloud provider accounts that
>>>>> 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:
>>>>1) 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
>>>1. Install Katello
>>>2. Install Aeolus and configure it so it knows how to reach Katello
>>>3. Configure Katello so it knows how to reach Aeolus
>>>4. In the Katello UI, choose an org and an environment to work in
>>>5. In the Katello UI, define a system template (please update this as
>>>required to reflect my imperfect knowledge of Katello).
>>I'd rework as follows:
>>4. Login to the Katello UI, and select an org.
>>5. In the Katello UI, define a system template and promote into an
>>environment along with the required content.
>>>6. (OPTIONAL) In the Katello UI, choose a Conductor catalog to add the
>>>- OR -
>>>6. (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
>>6a. (OPTIONAL) In the Katello UI, choose a Conductor catalog to add
>>the template to.
>>7a. Behind the scenes, template is built into an image
>The issue with 7a is that we can't build the image until we know where
>to push it -- which requires we know what pool we want it to run in,
>which requires the user to choose a pool. So I tend to think that if
>you don't want to pick a pool (like in 6b), 6a is as far as you can
>go. Does that make sense?
Understand. So does IW store the templates in CDL format? Meaning
that 7a would change to:
7a. Behind the scenes, template is transformed into CDL and stored
in the IW.
The CDL template could then be built into an image at a later date
via Conductor I assume?
That seems like the right flow. It would also be possible to simply
say "The Katello template is now visible in a catalog, the catalog
understands how to convert it to something Image Factory understands
and build it when required." I don't have a strong preference here.
>>6b. (OPTIONAL) In the Katello UI, choose an Conductor pool to launch
>>in (bypass catalog manipulation altogether).
>>7b. Behind the scenes, template is built into an image, pushed and launched.
>>8b. Running instance, is automatically registered back to Katello
>>for the given org and environment; as part of post-boot process.
>>9b. In the Katello UI, the system details will contain a link to the
>>Aeolus pool that the instance is running in.
>>>8. In the Katello UI, see a link to the Aeolus pool the image is
>>>THINGS TO NOTE ABOUT THIS STORY:
>>>1. 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.
>>>2. 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
>>>>2) 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.
>>>1. Assume a Katello already installed, with some available templates
>>>2. Install Aeolus, tell it how to reach Katello
>>>3. In the catalog management UI, choose "Add an application." UI
>>>Katello orgs/environments the user can see.
>>FYI...For now, Katello supports "system" templates or 1 template per
>>system. This will obviously need to change going forward to support
>Yeah, and for now I'm figuring we're only going to work with the one
>kind of Katello template that is available. But from the catalog
>management side, we may *call* that thing an application. Or we may
>not -- not completely sure.
>>>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.
>>9. Running instance, is automatically registered back to Katello for
>>the given org and environment; as part of post-boot process.
>>10. In the Katello UI, the system details will contain a link to the
>>Aeolus pool that the instance is running in.
>Yeah, 9-10 are good additions.
== 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."