On Aug 1, 2011, at 5:40 PM, Dmitri Pal <dpal(a)redhat.com> 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 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
>>>>> 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 of
>>>>> 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
>>> 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
>>> 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?>...
The first mail in the thread has a pretty good description of what catalogs are and what
features they need to have for this iteration.
* A catalog is an admin-defined collection of deployables, which in the Katello world are
also known as application templates
* A catalog can be added to 1 or more pools in Conductor by an administrator
* If a catalog has been added to a pool, then users with permissions to launch
applications in that pool have the applications in the catalog available to them to
Andy can expand further if need be...
Sr. Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?
aeolus-devel mailing list