Don't assume network names of "public" and "private"

[mikelococo]

The get_ip method currently assumes that the server.addresses hash will contain "public" and "private" keys. While that's a common convention, the presence of those keys isn't guaranteed, it depends on what the Openstack admin named the networks at creation time. Instead, use server.public_ip_address and server.private_ip_address. Those methods are dropin replacements for server.addresses['public'].first['addr'] and server.addresses['private'].first['addr'], and don't depend on network naming conventions.

For some more background on this issue, see the following fog issue (it's listed as still open, but the current behavior as of 1.15.0 is what you want for the get_ip method):
fog/fog#1529

[hartmantis]

Thanks for the tip. The last time I tested it, public_ip_address had a breaking bug in it, but I'll take another look.

[mikelococo]

I somehow missed the openstack_network_name config option, which allows one to workaround this bug, lowering the priority. Still, it would "just work" without manual config in more cases by using the fog methods instead of parsing the addresses hash.

FYI: vagrant-openstack-plugin just merged a PR to do things this way: https://github.com/cloudbau/vagrant-openstack-plugin/issues/16

[hartmantis]

@mikelococo So I finally got a little time to look into this today, and either rediscovered the problem I had last time or found a new one.

Those Fog methods fail when called against OpenStack deployments that don't load the extension for floating IPs (e.g. Rackspace's public cloud).

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

Not quite sure if the error is Rackspace's (for not loading that extension), Fog's (for assuming everyone has it), or mine (for trying to use Fog's OpenStack code against Rackspace). Would you object if I used those two methods first but still fell back to parsing the hash if needed?

[mikelococo]

1. It makes perfect sense to me to attempt the simple methods first, try to catch the common Rackspace error case with heuristics (like assuming public/private key names), then finally fall back manual config via the openstack_network_name option.

2. Fog does have a Rackspace provider, my guess is that they would recommend to use that instead of the Openstack provider when using Rackspace clouds. I would assume all these rough edges are filed away in that provider, though I haven't tried it.

3. I'll create a bug with your stacktrace over with fog-openstack and link it to this bug just in case they are interested in knowing about/solving for the no-floating-extension case in these methods. It seems to me like they'd want to be robust against all likely possibilities.

[hartmantis]

Thanks again for your input. #19 should take care of it, but let me know if you have any further issues.