[katello-devel] Improving Aeolus + Katello integration

[Hugh O. Brock]

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.

Take care,
--Hugh

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