[katello-devel] Improving Aeolus + Katello integration

[James Labocki]

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

The real value to end users would be if we could take changes in an image and rectify them to the build description (component outline) and then systematically update the images if a user desired. The key is having workflow and ties between imagefactory/foreman/puppet. Also, I would also submit it's important to keep our eyes on the horizon and understand the openshift cartridge framework and how it fits into the story as well.

https://bugzilla.redhat.com/show_bug.cgi?id=842755

-James


> 
> 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
> > 
> > 
> > 
> > 
> 
> --
> == Hugh Brock, hbrock at redhat.com                                   ==
> == 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
>