[chef] Re: Re: Re: Best practices: Search dynamically using templates in attributes


Chronological Thread 
  • From: Lamont Granquist < >
  • To: < >
  • Subject: [chef] Re: Re: Re: Best practices: Search dynamically using templates in attributes
  • Date: Thu, 31 Jan 2013 14:31:03 -0800

On 1/31/13 2:31 AM, Maxime Brugidou wrote:
" type="cite">
I understand that it looks ugly to put the search string in node attributes. However I dislike having a separate environment per DC, we have many DCs and I don't want to manage them separately. Prod, preprod, test and dev are logical environments and not related to the physical location (which is a simple ohai attribute to me), and I don't want to add 3 or 4 environments every other month when we open a new DC or update a dozen environments just because we change a value in a logical environment.

Additionally if you're searching for something like DNS or NTP servers, then you really don't want to have those defined per-software-environment.  If you have a complicated software staging in a large enterprise you might have something like:

dev -> test -> int -> [ load, partner-int ] -> partner-load -> prod

And you may have all those environments in one datacenter, and operationally for systems-level services like LDAP, DNS, NTP, etc I'm probably going to make a cut somewhere between internal services and external-SLA-affected services and I'll only have two clustered instances of those services for datacenters (probably the primary one for the enterprise) that have all of these environments.  I may also want to put all the stuff that doesn't map onto the software development life cycle into a completely separate environment so that when SDEs play with version pinning in their environments, they never stomp the DNS servers.

Having an instance of everything in every software app stage sounds slick (and would probably work if LDAP, DNS and NTP were the extent of it all), but as the enterprise scales that SDE-centric view of enterprise IT *will* completely fail.  When you're small enough to load it all up on a single small EC2 instance and the tax is low it works, but when you start dealing with 20+ virts and a bunch of repo mirrors that define the 'base' of a single DC, then the tax for doing things this way will be prohibitive.

I like the idea of pushing search queries into attributes and letting people override them in their roles or in their role cookbooks.




Archive powered by MHonArc 2.6.16.

§