Joel Merrick <joel.merr...@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 ✉ dan...@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-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.
