----- Original Message -----
From: "Hugh O. Brock" <hbrock(a)redhat.com>
To: "Ivan Nečas" <inecas(a)redhat.com>
Cc: aeolus-devel(a)fedorahosted.org, katello-devel(a)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(a)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