[chef] Re: Re: Re: Chef client managing remote systems?

[Daniel DeLeo < >]

On Monday, September 28, 2015 at 12:02 PM, Rafał Trójniak wrote:
> Thanks for the response Ranjib.
>  
> Using the scripts, or only LWRPs will cut off lot of Chef functionality
> I really appreciate : (Chef node) :
> - Searching for nodes
> - Node attributes auto-discovery (IP address, version and so one)
> - Applying roles, environments and run-lists for nodes
> - Organizing nodes in environments
>  
> We can see that with the AWS resources
> https://supermarket.chef.io/cookbooks/aws
>  
> Let's imagine we can use the each ELB instance as separate chef node.
> That would result in :
> - Discovery of ELB using chef search (like in back-ends or monitoring)
> - Assignment of that ELB to environment
> - Information when was it last configured by ohai_time (or similar)
> - Ability to configure each ELB separately
>  
> What do you thing about that approach ?
>  
> Regards,
>  

You can sorta get this working by using a separate chef-client config for 
each “virtual node” on the management host, by setting a different 
`node_name` for each one. Unfortunately, each one would also need a keypair; 
while the server would allow one client/key to manage many node objects, 
chef-client hardcodes client_name == node_name.

Ohai would run against the management host, and Chef would likely be borked 
if you modified the platform/platform family attributes, but you could use 
the minimal ohai flag to reduce the amount of extraneous attributes ohai 
collects, and make a cookbook that collects data about the network boxes and 
adds it to the automatic attributes (thus doing what ohai would do). The fqdn 
attribute may be changed if you set the node_name setting in the client.rb 
(and you would have to do this anyway so that chef saves the node data 
separately for your virtual nodes).

--  
Daniel DeLeo