> From: Michael Stahnke <stahnma@puppetlabs.com>
>
> On Mon, Oct 22, 2012 at 5:31 AM,  <John.Florian@dart.biz> wrote:
> >> From: Seth Vidal <skvidal@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