Fixing Puppet in Fedora/EPEL

John.Florian at dart.biz John.Florian at dart.biz
Mon Oct 22 12:31:28 UTC 2012


> From: Seth Vidal <skvidal at fedoraproject.org>
> 
> On Fri, 19 Oct 2012, Michael Stahnke wrote:
> 
> > On Fri, Oct 19, 2012 at 4:22 PM, Seth Vidal 
> >>
> >>
> >>
> >> On Fri, 19 Oct 2012, Michael Stahnke wrote:
> >>
> >>> I (we) completely realize this isn't totally awesome either.  This 
is
> >>> a problem when you have a distributed application that is trying to
> >>> support the widest variety of host populations we can.
> >>>
> >>> This request was brought to us by community members, Red Hat
> >>> employees, and business partners as well.
> >>>
> >>> I am happy to discuss other soutions/ideas too though.  I am not 
100%
> >>> convinced my proposal is the best.
> >>>
> >>
> >> I'm less worried about the people requesting the newness b/c they 
clearly
> >> want change. I'm worried about the people who run rhel b/c they 
> fear change.
> > I'm more worried about people with hybrid environments where RHEL is
> > at the core for Puppet. (and somewhat how RHEL 7 could shake out)
> >
> > Do you consider it ok to not be able to have Fedora agents check into
> > a RHEL master?
> >
> 
> There is a reason I want to move to a clientless configmgmt 
> infrastructure.
> 
> I do not want to be hogtied like this again.

I cannot speak for Fedora infrastructure, but I committed to puppet 
completely at work at home before realizing the horrible situation that 
puppet's client/server has forced on its users.  While it looks like 
they're heading in the right direction, it does us early adopters no good 
to struggle through this incompatibility entanglement.  Too much of what 
once was shown as "the way", if not the best practice, is no longer even 
supported (e.g., dynamically scoped variables).

My first use of puppet required operation from cached resources on 
stateless Fedora nodes in the event that the network was offline or the 
"master" otherwise unreachable.  I could not make the normal client/server 
approach work and thus adopted a rsync + cron + puppet agent apply 
approach as a work around.  That to date has still been my best experience 
with puppet -- it just works because it abandons the requirements imposed 
by their client/server approach. 

As for what should be done with Fedora and RHEL I cannot say.  It seems 
all available options stink.  On one hand I'd hate to see F17 change, I'm 
still struggling to adjust my code to be compatible with that.  I've had a 
difficult time keeping my puppet resources in shape for each Fedora 
release -- six months goes by all to fast when you have many other 
responsibilities -- puppet was supposed to reduce my workload, right? 
Right???  If 3.0 lands in F17, that's going to hurt my plans.  At the same 
time, puppet in F17 "as is" is plagued with problems as already mentioned.

 Argh!  "Hogtied" is a very apt description.

--
John Florian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20121022/58d6fe92/attachment.html>


More information about the devel mailing list