[chef] Re: RE: Re: RE: Re: RE: fqdn and Chef Server


Chronological Thread 
  • From: Daniel DeLeo < >
  • To:
  • Subject: [chef] Re: RE: Re: RE: Re: RE: fqdn and Chef Server
  • Date: Thu, 29 May 2014 14:38:27 -0700



On Thursday, May 29, 2014 at 2:15 PM, Kadel-Garcia, Nico wrote:

> It shouldn't, according to the README .md, " If the attribute 
> node['machine_fqdn'] is set, it will use the string found there to attempt 
> to configuration the machine's hostname." It's a new option in the latest 
> production code. It's also a violation of the coding standards where 
> attributes should be associated with their particular cookbook. Ideally, 
> the attribute would be "node['fqdn']['machine_fqdn']".


node[“fqdn”] is already set to a string value by ohai, so the cookbook can’t 
use it’s name to namespace the attributes.
  
>  
> As it stands, specifying that attribute on a host by host basis is not very 
> practical. It means that each host would need its own role or environment 
> to have the FQDN applied reliably.
>  

I’m not familiar with the cookbook, but I think the idea is that you write 
some code to determine the fqdn you want in a recipe, then set this value, 
e.g.:

# cookbook mycorp-fqdn, recipe default.rb

random_tag = node[“host_random_tag”] || rand(1_000_000).to_s(16) # a unique 
component for your host’s name
node.set[“host_random_tag”] = random_tag  # store the tag in node-specific 
storage so you get the same name next chef run
primary_role = node[“primary_role”] # set this in a role, role cookbook, etc.
subdomain = node.chef_environment # assuming your chef environments map to 
subdomains

node.override[“machine_fqdn”] = 
“#{primary_role}-#{random_tag}.#{subdomain}.example.com”

include_recipe “fqdn"

That would give you FQDNs like 'appserver-32f4f.staging.example.com'. Should 
be easy enough to generalize it for your own naming scheme.


--  
Daniel DeLeo




Archive powered by MHonArc 2.6.16.

§