- 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.