> From: Michael Stahnke <stah...@puppetlabs.com> > > On Mon, Oct 22, 2012 at 5:31 AM, <john.flor...@dart.biz> wrote: > >> From: Seth Vidal <skvi...@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
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel