Hi Pupeteers! I have a few questions regarding workflow that I''d appreciate insight from you guys on.. 1) How do people manage services that can''t be affected all at once? For instance, we run a number of DNS caches behind load balancers at two different sites and (not that I''d do this!) if for example I set bind to always be latest, how do I ensure that the puppet run doesn''t restart all my caches at once? Am I best to include the geographical and logical information about what cluster they are in as data or facts within the class, or is it better to subclass.. say bind::cache::siteA etc..? Is there any kind of splay mechanism? 2) When working with a number of git branches (for test, dev, prod) how do you manage the merges between them? Any links to this would be appreciated. I''m a git/puppet newb (as you can probably tell!) Cheers Joel -- $ echo "kpfmAdpoofdufevq/dp/vl" | perl -pe ''s/(.)/chr(ord($1)-1)/ge'' -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi, On Tue, Oct 26, 2010 at 3:21 PM, Joel Merrick <joel.merrick@gmail.com>wrote:> > 1) How do people manage services that can''t be affected all at once? > For instance, we run a number of DNS caches behind load balancers at > two different sites and (not that I''d do this!) if for example I set > bind to always be latest, how do I ensure that the puppet run doesn''t > restart all my caches at once? Am I best to include the geographical > and logical information about what cluster they are in as data or > facts within the class, or is it better to subclass.. say > bind::cache::siteA etc..? Is there any kind of splay mechanism? >I think if puppet client daemon is running in the listen mode, you can trigger puppet runs (using puppetrun) with a splay option. There are other approaches as well, you can find a bunch of discussions on the list. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Joel Merrick <joel.merrick@gmail.com> writes:> I have a few questions regarding workflow that I''d appreciate insight from > you guys on.. > > 1) How do people manage services that can''t be affected all at once? > For instance, we run a number of DNS caches behind load balancers at > two different sites and (not that I''d do this!) if for example I set > bind to always be latest, how do I ensure that the puppet run doesn''t > restart all my caches at once?One of two ways: one is to use some system outside of puppet to do this; we used mcollective, condor[1], and ssh[2] to do this, scheduled by some intelligent central authority with network-wide knowledge. The other is to use puppet to perform the work, and to use the PuppetCommander[3] mcollective plugin. This allows you to schedule puppet runs from a central service. With this you can configure, for example, concurrency per collection of machines, where "collection" is defined as any mcollective search. (Presently this requires one instance of PuppetCommander per collection, but the overhead is quite small.) This will run puppet with as much concurrency as you specify, but no more, allowing you to safely set the maximum number of machines running puppet[4] to whatever you want - and as long as that is below the N in your N+M servers for the service you can be confident it will not bring down everything at once. Puppet presently does not do this internally, as it doesn''t have the real-time network wide information required to make the appropriate decisions.> Am I best to include the geographical and logical information about what > cluster they are in as data or facts within the class, or is it better to > subclass.. say bind::cache::siteA etc..? Is there any kind of splay > mechanism?I would strongly urge you to put geographic and logical "location" information into custom facts, and ideally to infer that from the machine rather than require it declared for you. (This is based on experience with doing that by hand, by declaration, and by inference; the last one was by far the least painful choice.)> 2) When working with a number of git branches (for test, dev, prod) > how do you manage the merges between them? Any links to this would be > appreciated. I''m a git/puppet newb (as you can probably tell!)Merging between them? Just like you would any other git project: test your test branch thoroughly[5], then merge it up to the next branch: git pull # ...from your central server git checkout test # ...or whatever git pull dev # ...merges your changes # ... whatever git push # off we go to the central server again However, that is the most ... trivial approach; git has a whole lot more workflows, and I (or others here) can make recommendations for git resources that talk about a whole lot of ways to do all this. Anyway, the essence of my answer here is: puppet works just like any other project when it comes to merging and branch promotion with git. You don''t need do anything special in that regard. Regards, Daniel Footnotes: [1] Not ideal; while it works, and provides the requisite scheduling tools, it is not designed to the purpose and had substantially more latency than we really could afford. [2] Obviously using one of the modes that doesn''t require user interaction. [3] http://code.google.com/p/mcollective-plugins/wiki/PuppetCommander [4] ...absent third party actors like your sysadmins manually running puppet on the node, or any other scheduling tool. [5] I am assuming your question isn''t "how do I test that". If that assumption is incorrect please let me know. :) -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Tue, Oct 26, 2010 at 11:35 AM, Daniel Pittman <daniel@rimspace.net> wrote:> > The other is to use puppet to perform the work, and to use the > PuppetCommander[3] mcollective plugin. This allows you to schedule puppet > runs from a central service. > > With this you can configure, for example, concurrency per collection of > machines, where "collection" is defined as any mcollective search.That''s brilliant. I only became aware of MCollective yesterday (really intrigued by the exim stuff, can see it being extremely useful!) and I can see that fabric being a really good way of managing service. I''ll go off an do some reading regarding it. Many thanks for the heads up, you were spot on with the git question too. Joel -- $ echo "kpfmAdpoofdufevq/dp/vl" | perl -pe ''s/(.)/chr(ord($1)-1)/ge'' -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Joel Merrick <joel.merrick@gmail.com> writes:> On Tue, Oct 26, 2010 at 11:35 AM, Daniel Pittman <daniel@rimspace.net> wrote: >> >> The other is to use puppet to perform the work, and to use the >> PuppetCommander[3] mcollective plugin. This allows you to schedule puppet >> runs from a central service. >> >> With this you can configure, for example, concurrency per collection of >> machines, where "collection" is defined as any mcollective search. > > That''s brilliant. I only became aware of MCollective yesterday (really > intrigued by the exim stuff, can see it being extremely useful!) and I can > see that fabric being a really good way of managing service.*nod* MCollective was also recently acquired by Puppet Labs, so it is ... well, presumably related to the long term direction of the two products to work together.> I''ll go off an do some reading regarding it. Many thanks for the heads > up, you were spot on with the git question too.Glad I could help. Daniel -- ✣ Daniel Pittman ✉ daniel@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
----- "Joel Merrick" <joel.merrick@gmail.com> wrote:> Hi Pupeteers! > > I have a few questions regarding workflow that I''d appreciate insight > from you guys on.. > > 1) How do people manage services that can''t be affected all at once? > For instance, we run a number of DNS caches behind load balancers at > two different sites and (not that I''d do this!) if for example I set > bind to always be latest, how do I ensure that the puppet run doesn''t > restart all my caches at once? Am I best to include the geographical > and logical information about what cluster they are in as data or > facts within the class, or is it better to subclass.. say > bind::cache::siteA etc..? Is there any kind of splay mechanism?I use the mcollective method and often combine it by making my modules and package versions configurable using extlookup. Then I simply update extlookup for a specific location/client/environment to manage the roll outs. It''s a bit more manual but you know what you get and when. avoid using ensure => latest. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.