Fixing Puppet in Fedora/EPEL

[Michael Stahnke]

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

I'm sorry if your Puppet experience isn't completely awesome.  Posting
on the Puppet users list might be more appropriate.

In this case I am looking for packaging options/opinions on Puppet
with regards to Fedora and EPEL.
>
> --
> John Florian
>
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel