Fixing Puppet in Fedora/EPEL

[John.Florian at dart.biz]

> From: Michael Stahnke <stahnma at puppetlabs.com>
> 
> On Mon, Oct 22, 2012 at 5:31 AM,  <John.Florian at dart.biz> wrote:
> >> 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 
onstateless
> > 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 approachas 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???  If3.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.
> 
> I'm sorry if your Puppet experience isn't completely awesome.  Posting
> on the Puppet users list might be more appropriate.

Been there, done that since v0.24.  If I'd jumped in with 3.0, my opinions 
might be different.  I believe something like puppet is sorely needed and 
it solves big problems, but it's been a very bumpy ride when what was once 
"best practice" is now deprecated.
 
> In this case I am looking for packaging options/opinions on Puppet
> with regards to Fedora and EPEL.

See my next to last paragraph beginning, "As for what should be done with 
Fedora and RHEL ...".  Consider the rest as context.

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