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
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:
>>>>
>>>> 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
important)
>>>
>>> 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
>>> launched.
>> 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
>> **Done**
> 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.
>> **Done**
>>
>>> 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.
>
> --H
>
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.
Is it:
* 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
Alternatively:
* There are pools in the system
* Each pool/env can have several catalogs
* Each catalog contains already built images (deployables) for a
specific pool
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.
In short:
* 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
launch.
Andy can expand further if need be...
Take care,
--Hugh
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IPA project,
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel