[katello-devel] Deployable and System Template Portability

Wed Aug 22 11:10:03 UTC 2012

----- Original Message -----
> From: "Hugh Brock" <hbrock at redhat.com>
> To: "James Labocki" <jlabocki at redhat.com>
> Cc: "Bryan Kearney" <bkearney at redhat.com>, aeolus-devel at lists.fedorahosted.org, katello-devel at redhat.com
> Sent: Tuesday, August 21, 2012 10:52:49 AM
> Subject: Re: [katello-devel] Deployable and System Template Portability
> 
> 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).

Me too. In recent times when I begin to discuss both build-time configuration, run-time configuration, and incorporating drift management into the ability to automatically generate configuration content, changesets, and promotions (Dev-Ops with control?) users and customers get really excited. My perfect world would go something like this.

* Developer deploys an application via aeolus-conductor
* Developer makes change to httpd.conf (for example)
* Katello using Foreman and Puppet discovers the change was made
* Katello notifies SysAdmin about the change and presents a piece of puppet that would apply the change
* SysAdmin accepts the change and a new changeset is created with the piece of puppet content
* SysAdmin promotes changeset to the next environment
* httpd.conf file is altered in next environment

To me, this use case is VERY powerful because developers can simply go about configuring an application and aeolus/katello are generating content based on the changes. I'm sure I oversimplified the process.

> 
> > > >> 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?

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.

> 
> --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
> 