On Tue, Aug 14, 2012 at 09:12:51AM -0400, James Labocki wrote: > > ----- Original Message ----- > > From: "Bryan Kearney" <[email protected]> > > To: [email protected], [email protected] > > 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, [email protected] == == 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
