Re: Fixing Puppet in Fedora/EPEL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: Seth Vidal <skvidal@xxxxxxxxxxxxxxxxx>
>
> 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

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux