[katello-devel] Improving Aeolus + Katello integration

[Ivan Nečas]

On Thu 26 Jul 2012 08:15:30 PM CEST, Ian McLeod wrote:
> On Tue, 2012-07-24 at 11:13 -0400, Hugh O. Brock wrote:
>> 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?
>
> Adding puppet to the list of Factory customization steps is entirely
> possible.  Issues that come to mind:
>
> * The details of what is actually in the image will now be spread
> between the TDL itself and the configuration on the puppet server.  (And
> perhaps this is a good thing for some people.)
>
> * For snapshot-style builds, we need to ensure that the remote JEOS
> instance (on, for example, EC2) can communicate with the puppet server.
>
> * At least some of the puppet rules and use cases I have seen involve
> actions that are based on the unique identity of the host being modified
> or involve building out that identity by doing things like bootstrapping
> into a kerberos environment, establishing SSH host keys, etc.
> Obviously, these kinds of things cannot happen at image creation time.
> (Or, in the best case, they need to be repeated at instance creation
> time.)
If prepared properly, puppet manifests can be applied even without the 
master present. Especially, if the user that prepares the manifests 
counts on the fact, that it could be run without master (which is not 
so hard to test),  he could then benefit significantly from this. He 
probably still might want to rerun it on instance creation time, but 
it's much faster then running against a JEOS.

-- Ivan
..
>>> 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?
>>
>> There's some interesting work going on with cloud-init that may
>> eliminate the Audrey requirement. Joe Vlcek is driving that, we might
>> check with him.
>>
>> --Hugh
>>
>>> Ohad:
>>>
>>> How does Foreman solve the EC2 deployment against Foreman?
>>>
>>> --
>>> Ivan
>>>
>>>
>>>
>>>
>>
>



--
Ivan