You mention how you're looking into External Nodes - how do you currently decide which machines receive which configuration?
We had previously done this through hostnames (where each a portion of the hostname was a class that was to be applied to the node), but I'm looking to move away from hostname-based certnames and toward a static ID (like you mention in your paper). Doing this would break our external node classifier script - so I'm debating my next step while collecting information from others. Thanks! On Sun, Jun 6, 2010 at 4:26 AM, Nicolas Szalay <nsza...@qualigaz.com> wrote: > Hello, > > ----- "Patrick" <kc7...@gmail.com> a écrit : > | On Jun 5, 2010, at 2:31 PM, Chuck wrote: > | > | > I am currently worried about scalability as the number of modules > | and > | > clients on my puppet server increases. I am planning on locating > | at > | > least one puppet server in each of the 4 data centers. > | > | I've found that very bad things > > Why ? I know some people here do it, with some real success. Having your > master near your clients is, to me, a good thing. Use a central master to > configure satellite ones. The only problem is about SSL chaining that can > drive you crazy :p > > | > I am not finding any information on what to expect and to design > | into > | > my infrastructure as it matures so I don't run into any unexpected > | > surprises. It sounds like some people are using puppet in large > | > environments and I would like to know what the issues that have > | been > | > run into and if there is a way to design the environment to avoid > | > these issues. I have been reading through the puppet mailing > | lists, > | > wiki, and documentation which has gotten me to my current use of > | > apache/passenger. > | > | I'm not exactly sure what you want, but here's some general scaling > | advice: > | > | If you are using storeconfigs, take a look at > | http://www.masterzen.fr/2009/03/18/omg-storedconfigs-killed-my-database/ > | > | You probably want to use the "splay" option. Normally it won't help > | much, but it will help make sure that the puppet clients don't all get > | "in sync" and all try to connect to the server at once. > | > | I've heard that using RubyEE or JRuby can help reduce the amount of > | ram you need. > > There's a queue daemon now, you should take a look at this > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com<puppet-users%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- Gary Larizza Director of Technology Huron City Schools http://www.huronhs.com 悟 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
