[katello-devel] Improving Aeolus + Katello integration

[Bryan Kearney]

On 07/25/2012 05:56 AM, Ivan Nečas wrote:
> On 07/24/2012 05:31 PM, James Labocki wrote:
>>
>> ----- Original Message -----
>>> From: "Hugh O. Brock" <hbrock at redhat.com>
>>> To: "Ivan Nečas" <inecas at redhat.com>
>>> Cc: aeolus-devel at fedorahosted.org, katello-devel at redhat.com
>>> Sent: Tuesday, July 24, 2012 11:13:15 AM
>>> Subject: Re: Improving Aeolus + Katello integration
>>>
>>> On Mon, Jul 16, 2012 at 06:57:08PM +0200, Ivan Nečas wrote:
>>>> With funzo, we're trying to figure out how the Aeolus + Katello
>>>> could
>>>> better integrate together.
>>>>
>>>> The templates in Katello are going to be replaced with component
>>>> outlines. In
>>>> discussion about Foreman integration, it was not mentioned, that
>>>> the
>>>> Compontent Outline will contain the list of packages (System
>>>> Template
>>>> like we know it today has it). This is not required by Foreman
>>>> (Foreman
>>>> solves it with Puppet), but Aeolus is able to take the list of
>>>> packages and install it into the built image, if I understand it
>>>> correctly. Was it meant to be this way, or we just skipped it when
>>>> talking about Foreman. It seems quite valuable Aeolus feature to
>>>> me.
>>> Yeah, users do want to be able to do image based provisioning, in
>>> some
>>> cases with quite complex images. In fact I was discussing with Ian
>>> Mcleod the other day the idea that Factory might need to grow the
>>> ability to invoke Puppet after it finishes running the native
>>> installer when building the image (or running scripts on a pre-build
>>> JEOS).
>>>
>>> Another option, quite seriously, would be to look at having Factory
>>> use Puppet to resolve package requirements just as Foreman
>>> does. Historically we have shied away from this approach because RPM
>>> should take care of packaging requirements... but if we want to build
>>> something that isn't RPM based, well, that won't work. Factory guys,
>>> any thoughts?
>>>
>>>> Another thing to solve is how to call back to Katello after the
>>>> instance was deployed by Aeolus (if we're not satisfied with the
>>>> current status of setting the script manually in deployable, which
>>>> I
>>>> guess we're not). It seems for now that Audrey is the only way how
>>>> to
>>>> run some scripts after the image was deployed. Will there we some
>>>> other
>>>> way for running scripts after deployment in Cloud Engine. If not,
>>>> it
>>>> seems that we will need to run Audrey and Puppet side by side.
>>>> Maybe
>>>> it's ok, just asking, if its acceptable  to have two config servers
>>>> run
>>>> against the same machine?
>> I think we are close to solving an important problem that has plagued
>> IT ops. The ability to make changes to a running system (in dev, for
>> example) and then bring those changes back into the system description
>> to then promote to other environment seamlessly (QA, prod for
>> example). From my point of view we have the following technologies.
>>
>> Provisioning
>>   build based (katello)      - component outlines in katello
>>   image based (imagefactory) - images built from component outline
>>
>> Run-time configuration
>>   audrey         - used for boot time config
>>   foreman/puppet - after boot, used for ongoing configuration management
>>   cloud-init     - not sure where this fits exactly yet, but I guess
>> it might replace audrey

I jhad assumed that we would use TDl for build time config, and 
cloud-init / audrey for initial boot "Find your katello" and then use 
puppet for initial build time config and ongoing drift. Granted you 
could do more config via  TDL but what I described would be best 
practice. I had not assmed puppet at buld time would be a high priority.

-- bk