Openstack methods assume the extension for floating IP's is loaded

[mikelococo]

server.public_ip_address and server.private_ip_address fail when executed against an Openstack implementation without the floating-ip extension loaded. I'm not sure how common this is, but Rackspace does it. While fog has a separate Rackspace provider, other small openstack implementations may follow their lead on config options.

Stacktraces:

irb(main):006:0> server.public_ip_address
Fog::Compute::OpenStack::NotFound: Fog::Compute::OpenStack::NotFound
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/excon-0.25.3/lib/excon/middlewares/expects.rb:10:in `response_call'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/excon-0.25.3/lib/excon/middlewares/response_parser.rb:8:in `response_call'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/excon-0.25.3/lib/excon/connection.rb:349:in `response'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/excon-0.25.3/lib/excon/connection.rb:247:in `request'
from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/fog-1.15.0/lib/fog/core/connection.rb:57:in `request'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/fog-1.15.0/lib/fog/core/deprecated/connection.rb:20:in `request'
   from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/fog-1.15.0/lib/fog/openstack/compute.rb:339:in `request'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/fog-1.15.0/lib/fog/openstack/requests/compute/list_all_addresses.rb:10:in `list_all_addresses'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/fog-1.15.0/lib/fog/openstack/models/compute/server.rb:95:in `all_addresses'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/fog-1.15.0/lib/fog/openstack/models/compute/server.rb:110:in `floating_ip_addresses'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/fog-1.15.0/lib/fog/openstack/models/compute/server.rb:116:in `floating_ip_address'
    from (irb):6
    from /usr/local/bin/irb:12:in `<main>'

irb(main):007:0> server.private_ip_address
Fog::Compute::OpenStack::NotFound: Fog::Compute::OpenStack::NotFound
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/excon-0.25.3/lib/excon/middlewares/expects.rb:10:in `response_call'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/excon-0.25.3/lib/excon/middlewares/response_parser.rb:8:in `response_call'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/excon-0.25.3/lib/excon/connection.rb:349:in `response'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/excon-0.25.3/lib/excon/connection.rb:247:in `request'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/fog-1.15.0/lib/fog/core/connection.rb:57:in `request'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/fog-1.15.0/lib/fog/core/deprecated/connection.rb:20:in `request'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/fog-1.15.0/lib/fog/openstack/compute.rb:339:in `request'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/fog-1.15.0/lib/fog/openstack/requests/compute/list_all_addresses.rb:10:in `list_all_addresses'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/fog-1.15.0/lib/fog/openstack/models/compute/server.rb:95:in `all_addresses'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/fog-1.15.0/lib/fog/openstack/models/compute/server.rb:110:in `floating_ip_addresses'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/fog-1.15.0/lib/fog/openstack/models/compute/server.rb:122:in `private_ip_addresses'
    from /usr/local/Cellar/ruby/1.9.3-p392/lib/ruby/gems/1.9.1/gems/fog-1.15.0/lib/fog/openstack/models/compute/server.rb:126:in `private_ip_address'
    from (irb):7
    from /usr/local/bin/irb:12:in `<main>'

This was discovered while testing kitchen-openstack: test-kitchen/kitchen-openstack#16

[geemus]

@krames - do you maybe have context or advice here?

[krames]

@mikelococo @geemus Let me dig into this and see if I can find some answers.

[hartmantis]

Thanks for looking into this. Nothing to add; just getting onto the CCs for any updates before I forget.

[krames]

I spoke with one of our networking guys and I was told that this was a fairly common implementation for an OpenStack installation.

Rather than catching these exceptions and returning nil, I believe we should try to create different strategies to retrieve an OpenStack address and make that configurable.

@RoboticCheese Do you know what strategy your installation is using?

[hartmantis]

@krames It's the v2 Cloud Servers where I first encountered it (I know there's separate Fog code for Rackspace, but I like to test against as many OpenStack environments as I can). I'm not sure if there's a specific name for that style of installation; I was talking to an OpenStack dev who used to be on my team and he noted that we/they return a 404 for floating IPs due to that extension not being in use.

I tested against our internal OpenStack deployment as well and got the same result.

[krames]

@RoboticCheese Thanks for the follow up. If you can, I would love to know how to get ip addresses for a server in your installation. Once you do that we can add this as a configuration option to fog.

[hartmantis]

@krames For whatever it's worth, the accessIPv4 attribute does work in the two environments that don't have floating IPs. It's empty for TryStack nodes, but they're already weird anyway and only assign private IPs.

It's sounding like the one true answer may be that there is no one true answer for the large variety of OpenStack deployments.

In that case, I'm cool with for now continuing just making a best guess at an IP between what I get out of server.public_ip_address, server.private_ip_address, server.accessIPv4, and server.addresses. Regardless, thanks for all your help, and giving me a reason to learn some new things about OpenStack networking. :)

[mikelococo]

The only addition I'd make to what @RoboticCheese has already said is that kitchen-openstack isn't the only project that has been tripped up by the fog-openstack's IP abstractions leaking complexity. I've hit it in closed-source projects, and vagrant-openstack hit it (https://github.com/cloudbau/vagrant-openstack-plugin/issues/16).

I get the sense that this is a right of passage for most users of fog-openstack...

1. Start with a simple but unreliable concept of how to get an ip address.
2. Find the public_ip_address and private_ip_address methods and rejoice at their simplicity.
3. Realize those methods are backed by complex and non-intuitive heuristics and can't be relied upon. Feel sadder about the world.
4. Decide to expose a network-name parameter and implement some kind of decision tree to look for that network-name in the addresses-hash, then try the public/private methods, then try to manually parse the addresses-hash in case all that fails.

I'm not sure how to drastically improve things... perhaps what's really needed is an improvement in the openstack API to radically simplify the simple/common cases of ip-address enumeration. But I do think that server.private_ip_address in particular should try very hard to return something so downstream devs can use it at the tail end of their decision tree and know that they'll get an address.

[gshively11]

We're blocked by this issue. chef-client blows up with an Excon::Errors:Forbidden error, due to this line:

fog/lib/fog/openstack/models/compute/server.rb

Line 147 in 639c5e3

ip_addresses - floating_ip_addresses

Explicitly telling fog to use the private ip for ssh still attempts to grab the list of floating ips, which is not supported in our installation of OpenStack. Any suggestions?

[krames]

@gshively11 As you probably know there are different strategies for allocating ip address in OpenStack and at the time this issue first occurred there was not a good way to programmatically retrieve an accessible ip address. I believe OpenStack was aware of this issue and was trying to address it, however, I haven't kept up with it.

TLDR; I do not think fog/chef is going to work out of the box for you. You might need to submit a pr to fix this.

@ @mdarby is this something you can help with?

[wolf31o2]

We have similar issues with caskdata/coopr-provisioner and the fog_provider plugin.

[fifieldt]

Coming up in OpenStack, the "don't care what you have to do, just get me a network" API:

http://specs.openstack.org/openstack/neutron-specs/specs/liberty/get-me-a-network.html
https://blueprints.launchpad.net/neutron/+spec/get-me-a-network

eta April 2016

[plribeiro3000]

Closing in favor of fog/fog-openstack#38