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 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
>>>> 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:
>>> 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
>> template to
>> - 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?
> 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
>> running in
>> 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 lists
>> 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
> "application" templates.
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.
I am sorry may be it was described somewhere but it is not clear to me
what is the hierarchy from user point of view regarding a catalog.
* There are catalogs in the system
* Catalogs contain predefined deployables
* Some deployables are just templates as they have not been associated
with the pools and environments
* Other deployables have been already associated with a specific
environment and thus catalog has already a prebuilt set of images for
each pool the deployable was tagged to.
This view dictates the following user workflow: Catalogs -> Catalog ->
Deployble -> Deployable for a specific pool
* There are pools in the system
* Each pool/env can have several catalogs
* Each catalog contains already built images (deployables) for a
This view dictates the following user workflow: Pools -> Pool ->
Catalogs -> Catalog -> Deployble
There might be some other (third or fourth) workflow that is implied in
the user stories above but I am not clear which one exactly.
Can we start with a definition of Catalog?
Catalog is the collection of <what?> that are <what?>...
Sr. Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?