[chef] Re: Re: Getting the ipaddress of a specific interface

[Haim Ashkenazi < >]

Hi Bryan,

On Mon, Aug 15, 2011 at 9:03 PM, Bryan McLellan < "> > wrote:

On Sun, Aug 14, 2011 at 9:54 PM, Haim Ashkenazi

< "> > wrote:

> Thanks, The gist I posted before does something similar. It's strange though
> that it has to be so difficult. Yesterday when the need came up, I thought
> it would be dead easy :(

The issue is complicated, which is the reason that we haven't resolved
that old ohai bug.

1) The JSON data for interfaces is structured as hierarchical
attributes of the parent, which seems to make sense.

 The interface has an attribute, which is an address, which has an
attribute which is a family:

 node[:network][:interfaces][:eth0][:addresses]["192.168.1.101"][inet]

 Which makes us do:

 node["network"]["interfaces"]["eth1"]["addresses"].select {
|address, data| data["family"] == "inet" }[0][0] => 192.168.1.101

2) However, the way our minds tend to work is:

 The interface has an address of a particularly family, usually ipv4 (inet).

 Because of this common need, what we tend to want is something like:

 node[:network][:interfaces][:eth1][:address][:inet] => 192.168.1.101

3) Which would be nicer. There is a tendency to want something like:
node[:ipaddress_eth1] or node[:ipaddress][:eth1] but these diverge
from the data hierarchy.

---

One desires to have a pointer syntax in JSON so that performing a
lookup in the second form (or an alternate) would provide the data
from the first. An option is to move from the first hierarchy to the
second, possibly storing data in both locations with a deprecation
message for the first for some period of time. Another option is that
we could just live with having this data in multiple locations.

Thoughts?

I must say, I actually don't have a preference regarding the options above, but I think that looking for a solution took way too long. The solution should either be clear when you look at the json provided by ohai (like option 2 or the solution provided by the ohai plugin from the gist) or it should be easily found in the wiki.

It just took me by surprise because I thought that a thing like this should have a big demand and this would cause it to be solved in either way :)

Thnaks

--
Haim