On 08/03/2011 07:27 PM, Dmitri Pal wrote:
On 08/03/2011 10:34 AM, Hugh Brock wrote:
> On Tue, Aug 02, 2011 at 08:13:55PM -0400, Dmitri Pal wrote:
>> On 08/02/2011 07:07 AM, Hugh Brock wrote:
>>> 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
>>> Andy can expand further if need be...
>> Bullet one talks about templates, bullet three about images.
>> It does not answer the question about the template to image transition.
>> When do the templates turn into images? Automatically when catalog gets
>> associated with pool or there is a special user action? Can catalog
>> associated with a pool contain just templates for one deployable and
>> images for another or catalog deals with just templates and image
>> creation is more viewed as a launch step?
> I *think* I said (maybe I didn't and just thought I did) that, when a
> user adds a catalog to a pool, there needs to be UI somewhere that
> will let the user see whether the images required for the deployables
> in the catalog are in one of three states: built and ready; built, but
> stale; or not built. The user should then be able to tell factory,
> from a UI in Conductor, to build them.
> This means: Really a catalog contains only deployables, that happen to
> reference images that will eventually be in the warehouse
> somewhere. In the early going building those images will be a user
> task, hopefully from the UI; later, we may add some automation.
> Does this make sense?
Hm I think I understand what you are talking about but that leads back
to the definition of the catalog and its purpose. If the purpose of the
catalog is to have a collection of usable deployables that a group of
people can launch in a pool then it seems that there should be a
workflow related to "publishing" something to a catalog.
I assume that the catalog relation to pool or pools should probably
established first before anything is published to a catalog. Then the
act of publishing is the point when the transformation from the
templates to images occur. In other words:
* Templates are associated with the catalog
* Images are built for the specific pools
* Right permissions derived from the catalog access are set on the
images if images can be accessed outside Conductor. Otherwise the images
do not need to have any permissions as the permissions can be defined on
a per catalog basis.
After some more thinking I nailed down the issue that was bothering me.
What is still not clear and not defined is the logical meaning of the
catalog. We have the technical meaning but not the logical. What is a
catalog for an end user? Is it a group of applications he and his team
can run in a specific environment? For example HR team can run HR
applications while Finance can run finance applications? One has HR
catalog to pick from and another Finance catalog to pick from. In this
case the access to the catalog means at least access to see and probably
launch applications. The model might allow (or not allow) Individual
people to have more granular permissions regarding editing of the images
in the catalog (unclear).
May be catalog has other meaning to the end users and it is more
pool/provider oriented. May be it is something else. The point is that
without defining the purpose of the catalog we would not be able to
define right permissions and workflows around it. May be I missed that
part. Sorry. But I do not remember that being clearly spelled out.
I hope my questions help to clarify how things are going to work together.
Sr. Engineering Manager IPA project,
Red Hat Inc.
Looking to carve out IT costs?