[katello-devel] Deployable and System Template Portability

[James Labocki]

----- Original Message -----
> From: "Justin Clift" <jclift at redhat.com>
> To: "Hugh O. Brock" <hbrock at redhat.com>
> Cc: aeolus-devel at lists.fedorahosted.org, "James Labocki" <jlabocki at redhat.com>, katello-devel at redhat.com, "Bryan
> Kearney" <bkearney at redhat.com>
> Sent: Thursday, August 23, 2012 6:40:43 AM
> Subject: Re: [katello-devel] Deployable and System Template Portability
> 
> On 22/08/2012, at 11:44 PM, Hugh Brock wrote:
> <snip>
> >> It sounds like a good idea at first glance, but I would be worried
> >> that all implementations would differ so widely. Maybe if when an
> >> application blueprint is imported in aeolus it could check if all
> >> the proper images exist (sort of like a checksum for a system
> >> image) and also could provide guidance on what packages are
> >> needed in each image? This would require aeolus having a deeper
> >> understanding of the katello environment.
> > 
> > The issue here is that we identify images by UUID, so no image is
> > ever
> > going to match from one Conductor setup to another. IOW there is no
> > way
> > Conductor *could* check to see "if the proper images exist" on
> > importing a blueprint, given the current setup.
> > 
> > We'd need to have two things to fix this:
> > 
> > 1. A way to guarantee image equivalence. Katello will have this
> > before
> > all that long with content views
> > 
> > 2. Given 1, a way to identify images that actually are equivalent.
> > 
> > These things are doable but not necessarily easy. Doesn't mean we
> > shouldn't do them of course...
> 
> As a potentially easy first step, and ignoring the nascent templates
> site for now, we can probably ship some default reference deployables
> with Aeolus right now.  ie.:
> 
>   Apache HTTP Server
>   JBoss Server (of some appropriate sort)
>   MySQL Server
>   Nginx Server
>   PostgreSQL Server
> 
> We could "reserve" some of the UUID address range for these
> kind of templates. ie:
> 
>   00000000-0000-0000-0000-xxxxxxxxxxxx
> 
> And then have the reference ones use known UUIDS:
> 
>   Apache HTTP Server == 00000000-0000-0000-0000-000000000001
>   JBoss Server       == 00000000-0000-0000-0000-000000000002
>   MySQL Server       == 00000000-0000-0000-0000-000000000003
>   Nginx Server       == 00000000-0000-0000-0000-000000000004
>   PostgreSQL Server  == 00000000-0000-0000-0000-000000000005
> 
> We'd probably add an aeolus-configure option for adding them.
> 
> i.e.:
> 
>   $ sudo aeolus-configure -p rhevm,vsphere,ec2,templates
> 
> If someone doesn't want to use those templates they don't
> have to.  However, most places will probably keep around
> the ones they have use for.
> 
> The above probably wouldn't be too hard to implement either,
> and gives people a kick start in getting running.

Would the templates already be binary images or component outlines pointing to a repo to build? If templates, would it be difficult to ship large binary images around as part of Aeolus? If component outlines, where would the point for packages?

It would be nice if the `aeolus-configure -p templates` option were coordinated with `katello-configure -p templates`. This would mean that all a user would need to do is:

1. `yum install aeolus-all`
2. `yum install katello-all`
3. `katello-configure -p templates`
4. import Red Hat Manifest and sync appropriate repos in katello (which might be highlighted by the "templates" configure option in katello)
5. `aeolus-configure -p templates`
6. build images (or maybe the "templates" option can kick builds off on behalf of the user?)

Having a way to share images between clouds in aeolus would also be nice in this scenario because it would be possible to move images between a "stage" could and "my" cloud if the images were built in a staging area.

Let me know if this sounds way off.


> 
> + Justin
> 
> --
> Aeolus Community Manager
> http://www.aeolusproject.org
> 
>