[katello-devel] Improving Aeolus + Katello integration

[Ohad Levy]

On 07/25/2012 06:21 PM, Hugh O. Brock wrote:
> On Wed, Jul 25, 2012 at 08:08:39AM -0400, Bryan Kearney wrote:
>> 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.
>
> I think you're right about this being the "best practice" workflow and
> the one we should try to solve *first*.
>
> Having said that, I have frequently heard from users who are committed
> to doing the opposite for whatever reason -- it doesn't seem to be an
> uncommon case at all. So I would like to support it at some point. If
> that means that the Factory should learn to do more config during the
> image build, then that seems like a worthwhile goal.

I'm still not clear of why not telling foreman to create an instance and 
pull that as an image. you would get 90% of the job done for free and 
you would only need to take care for cleaning up the instance from host 
specific stuff.

Ohad
>
> Take care,
> --Hugh
>