[chef] Re: Re: [chef: How do you manage multiple data centers

[Torben Knerr < >]

Hi Sascha,

that makes all sense.

I like the way you handle cookbook promotion. If I understood it right you pin only the top-level / main / application cookbooks in the environment, while the supporting / library cookbook versions are pinned in the metadata of the top-level cookbooks, right?

As for the dc specific stuff: agree, got me convinced that multiple prod environments per dc are a bad idea :-)

Another way to handle this apart from roles could be:
- define overrides for dc-specific node attributes in a databag
- use a cookbook at the beginning of the run list that reads this databag and calls node.override accordingly (wasn't there a hw cookbook exactly for this purpose?)

Just an idea though...

Cheers, Torben

On May 8, 2013 7:48 AM, "Sascha Bates" < "> > wrote:

Well, my gut feeling for this is that it's because, when I promote a cookbook, I want all my production servers to get that promotion. I don't want to have to promote for each data center.  I am specifically using my environments to control cookbook code promotion and if I had a need, to key off the name for organization-wide settings, like an integration URL that differs across environments.

For the record, when I say "promote a cookbook" I have 4 main cookbooks that represent server apps or profiles. Inside each of those cookbooks, the metadata points to the versions of supporting cookbooks it requires.  So I pin versions of my 4 main profiles in the production env. I don't "promote" supporting cookbooks, but instead bump version numbers whenever I make a change so that the metadata version dependencies for each profile cookbook is very specific.

Whatever secondary data container I settle on for dc-specific settings should be fairly static - local DNS, local package repos, whatever, requiring many fewer changes.

I'm afraid this might have rambled a bit. I probably should write technical emails when I'm falling asleep.

For the record, I appreciate everyone's input and have marked some of the Chef talks to also watch. I'm made this decision before and I've seen it made and disagreed with some implementations I've seen. My goal is to make the decision and not regret it in a few months.

Sascha



Torben Knerr wrote:

Hey guys,

this is theoretical, I'm not through this in practice yet:

From a aconceptual point of view, I'd argue to definitely use environments rather than roles for keeping the datacenter (=a different environment) specific attributes.

From the gut feeling I would have started with sth like 'prod_dc1' and 'prod_dc2' environments etc..

Did I get it conceptually wrong or are there other practical reasons why you are all using a single 'prod' env and managing the dc specific stuff in roles instead?

Cheers, Torben

On May 8, 2013 1:40 AM, "Jesse Nelson" < " target="_blank"> > wrote:

I've used internal DNS to denote locality. We use a contrived 4letter LTD and then use the datacenter as the first dot: i.e: 356sf.myorg, 365ny.myorg.  I know it violates the cardinal no metadata in name rule that I try to abide by, but this makes it pretty easy to handle data center specific needs via node.domain, and without the need for specific roles to locality. A single cook/role (or role cook) denotes all the specifics for each datacenter, and individual cooks can easily override if needed.