[katello-devel] Deployable and System Template Portability

[Hugh Brock]

On Tue, Aug 14, 2012 at 09:12:51AM -0400, James Labocki wrote:
> 
> ----- Original Message -----
> > From: "Bryan Kearney" <bkearney at redhat.com>
> > To: aeolus-devel at lists.fedorahosted.org, katello-devel at redhat.com
> > Sent: Tuesday, August 14, 2012 8:50:39 AM
> > Subject: Re: [katello-devel] Deployable and System Template Portability
> > 
> > On 08/14/2012 05:26 AM, Dmitri Dolguikh wrote:
> > > On 13/08/12 07:30 PM, James Labocki wrote:
> > >> Sorry for posting across both lists, but this involves both aeolus
> > >> and katello.
> > >>
> > >> Last week a few of us were discussing the ability to import/export
> > >> deployables within aeolus for sharing between differing
> > >> implementations.
> > >>
> > >> The attached photo 1.JPG provides a high level diagram of some of
> > >> the problems we believe exist in achieving this today. Please
> > >> note that I used enterprise nomenclature, so I think that:
> > >>
> > >> - System Engine     = Katello
> > >> - Component Outline = Assembly
> > >> - Blueprint         = Deployable
> > >> - AppForm           = Deployment
> > 
> > With Foreman Integration, the goal is to kill templates and model
> > component outlines off of Foreman Host Groups.
> 
> I'd like to see both these models supported in the future, is this the thinking behind using host groups or will it only support one of the scenarios?
> 
> Description + Host Group  ==> Build ==> Configured Image  ==> Push to Provider
> Configured Image at Provider ==> Launch ==> Connect back to Katello and make further changes to Host Group
> 
> OR
> 
> Description ==> Build ==> Unconfigured Image ==> Push to Provider
> Unconfigured Image at Provider ==> Launch ==> Connect back to Katello and make all changes based on Host Group

Hello James, thanks for bringing this stuff up.

We need to support both of these cases, I am aware of specific customer
demand for both. Bryan and I have been oversimplifying and referring to
them as "image-based" (the first one) and "build-based" (the second one).

> > >> We found the following areas differ between implementations and
> > >> would need to be accounted for. Note this this was not an
> > >> exhaustive exercise and I'm sure we missed some areas.
> > >>
> > >> - Providers paths are different in katello
> > >> - Certificates are different in system templates
> > >> - Repositories are different in system templates
> > >> - Deployables and their services are tightly coupled (not
> > >> shareable)
> > >> - Clouds, Cloud Resource Zones, and Catalogs are different in
> > >> aeolus
> > >>
> > 
> > Can you give examples of these issues? I would assume the TDL we are
> > generating is valid.
> 
> >From reply to Ivan earlier plus more information.
> 
> Customer A installs katello and creates Custom ProviderX with ProductY and RepoZ
> Customer B installs katello and creates Custom ProviderA with ProductB and RepoC
> 
> Customer A creates system template which references RepoZ, hands system template to Customer B.
> Customer B takes system template and imports it into his/her aeolus. The custom provider is does not exist in his system engine (assuming he changes the path the system engine host in the template) and the certs don't match. 
> 
> On the Aeolus side:
> 
> Image ID's don't match in the application blueprint that Customer A would share with Customer B which would contain the multiple images that make up an application. Also, services in the application blueprint will likely call environment specific variables which are not abstracted from the service.

We have been talking for a long time about the need for an image
abstraction in Aeolus that would let you reference an image by name
rather than UUID, such that as long as you have an image named "abc" in
your environment, then a deployable can find that image and use it.

Having said that, this image naming thing gets very quickly into service
definitions, a la Cloud Formations. My Cloud Formations app might
reference three services by well-known names, and it's the
responsibility of the underlying infrastructure to either point the app
to the right services or spin up instances that provide them. We don't
have this capability right now with Aeolus, of course, but we are
discussing various ways to get there.

In the meantime I would at the very least like to see us look at some
kind of abstraction for image names, repo names, and provider
names. Does that seem like it would solve the majority of these issues?

--Hugh

-- 
== Hugh Brock, hbrock at redhat.com                                   ==
== Engineering Manager, Cloud BU                                   ==
== Aeolus Project: Manage virtual infrastructure across clouds.    ==
== http://aeolusproject.org                                        ==

"I know that you believe you understand what you think I said, but I’m
not sure you realize that what you heard is not what I meant."
--Robert McCloskey