[katello-devel] Improving Aeolus + Katello integration

[Ian McLeod]

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

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

-- 
Ian McLeod - Red Hat
office: 312.660.3539
mobile: 312.899.6736
rh internal: (81) 33539