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

["Kadel-Garcia, Nico" < >]

>From: Daniel DeLeo 
>[mailto:
 
> On Behalf Of Daniel DeLeo
>Sent: Thursday, May 29, 2014 5:38 PM
>To: 
>
 
>Subject: [chef] Re: RE: Re: RE: Re: RE: fqdn and Chef Server

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

That's a valid point. It's still not a good reason to set attributes for a 
specific cookbook without a leading hash element. If necessary, I think the 
cookbook could be renamed.

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

The default value of the relevant 'node['machine_name'] attribute created, 
and tested, inside the library could be set to node['fqdn'] instead of being 
left 'nil' and the library test simply failing. It's not reasonable for a 
cookbook's default behavior, with no values manually added to environment or 
role or containing recipe caller to flat out fail. It should have a more 
typical default behavior.

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

That's a reasonable approach. Unfortunately, the breakage if 
node['machine_fqdn'] is *not* set is a new failure mode associated with the 
new cookbook, and I don't think it's reasonable. The README.md describes the 
setting of it to 'nil' as the default, but mentions nothing about that 
default breaking the cookbook. 

The cookbook has been useful up to now for various OS installers that 
disagree, all of them, about whether and where the FQDN belongs in 
/etc/hosts. I'm already testing some patches for this: I need to enhance them 
with the ability *not* to put the FQDN on the loopback, which is known to 
break junit for remote access.
--
Nico Kadel-Garcia
Senior Systems Consultant
Email: 

 
Cell Phone: +1.339.368.2428