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

[Jesse Nelson < >]

Maxime, I agree the fact that a node resides in a certain location shouldn't be prescribed it should be discovered. What does your ohai plugin do the discover the datacenter the node is in ?

On Wed, May 8, 2013 at 12:53 AM, Maxime Brugidou < " target="_blank"> > wrote:

We run chef on 7 datacenters and get the node's datacenter from an ohai plugin.

This is actually the cleanest thing to do, you don't have to manually set the node's DC anywhere since it's auto-discovered. When you need specific attributes per data center we use "wrapper" cookbooks that dynamically define attributes according to the DC.

On May 8, 2013 7:19 AM, "Torben Knerr" < " target="_blank"> > 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.