On Mon, Oct 22, 2012 at 5:31 AM, <John.Florian@xxxxxxxx> wrote: >> 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. 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
