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