On Aug 14, 2011 1:49 PM, "Haim Ashkenazi" haim.ashkenazi@gmail.com wrote:
I was wondering if there's an easy way to get the ip address of a specific
interface (and not just the main ip adders)?
It isn't as easy as it should be, but you can use this code to do it:
http://tickets.opscode.com/browse/OHAI-88
ipaddress_eth1 = host["network"]["interfaces"]["eth1"]["addresses"].select {
|address, data| data["family"] == "inet" }[0][0]
Bryan
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
Bye
On Mon, Aug 15, 2011 at 3:15 AM, Bryan McLellan btm@loftninjas.org wrote:
On Aug 14, 2011 1:49 PM, "Haim Ashkenazi" haim.ashkenazi@gmail.com
wrote:
I was wondering if there's an easy way to get the ip address of a
specific interface (and not just the main ip adders)?
It isn't as easy as it should be, but you can use this code to do it:
http://tickets.opscode.com/browse/OHAI-88
ipaddress_eth1 = host["network"]["interfaces"]["eth1"]["addresses"].select
{ |address, data| data["family"] == "inet" }[0][0]
Bryan
--
Haim
On Sun, Aug 14, 2011 at 9:54 PM, Haim Ashkenazi
haim.ashkenazi@gmail.com 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.
- 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
- 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
- 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?
Hi Bryan,
On Mon, Aug 15, 2011 at 9:03 PM, Bryan McLellan btm@loftninjas.org wrote:
On Sun, Aug 14, 2011 at 9:54 PM, Haim Ashkenazi
haim.ashkenazi@gmail.com 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.
- 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
- 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
- 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
On Mon, Aug 15, 2011 at 8:30 PM, Haim Ashkenazi haim.ashkenazi@gmail.comwrote:
Hi Bryan,
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
The previously referenced Ohai plug-in which has been listed on "Community
Plugins http://wiki.opscode.com/display/chef/Community+Plugins" for some
time now...
network_addr.rb https://gist.github.com/1040543
extends network attribute with additional ipaddrtype_iface attributes to
make semantically easier to retrieve the addresses. e.g.,
node['network']['ipaddress_eth0'] vs
node['network']['interfaces']['eth0']['addresses'].guesswhichisfirst.
Beyond that, I've now added the detail from this interaction to the
"Searchhttp://wiki.opscode.com/display/chef/Search"
page on the Wiki as well - for those instances where it arises in the
future. Hopefully between the two, the solution can be "easily" found,
pending a determination on how to best address OHAI-88.
Thanks,
Hi
On Tue, Aug 16, 2011 at 7:47 AM, Tom Thomas tom@opscode.com wrote:
On Mon, Aug 15, 2011 at 8:30 PM, Haim Ashkenazi haim.ashkenazi@gmail.comwrote:
Hi Bryan,
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
The previously referenced Ohai plug-in which has been listed on "Community
Plugins http://wiki.opscode.com/display/chef/Community+Plugins" for some
time now...
network_addr.rb https://gist.github.com/1040543
extends network attribute with additional ipaddrtype_iface attributes to
make semantically easier to retrieve the addresses. e.g.,
node['network']['ipaddress_eth0'] vs
node['network']['interfaces']['eth0']['addresses'].guesswhichisfirst.
Beyond that, I've now added the detail from this interaction to the "
Search http://wiki.opscode.com/display/chef/Search" page on the Wiki as
well - for those instances where it arises in the future. Hopefully between
the two, the solution can be "easily" found, pending a determination on how
to best address OHAI-88.
Great. Now when I search the wiki for ipaddress it actually comes as one of
the first results :). Previously if you didn't know you have to search for
ohai plugin (like me) you didn't know where to look for it.
Thanks,
--
Haim