Reverse the priority of floating_ip & floating_ip_pool

[StaymanHou]

In my case, I would like to have the ability to override the floating_ip_pool option with the floating_ip option.
I wanna have one suite running on an instance with the floating_ip I explicitely provided only for this suite. And the rest of the suites using the default setting which is retreiving a random ip from the floating_ip_pool.

my .kitchen.yml example

---
driver_config:
  require_chef_omnibus: true

driver:
  name: openstack
  openstack_username: "*********"
  openstack_api_key: "*********"
  openstack_auth_url: "http://mystack.com:5000/v2.0/tokens"
  openstack_identity_endpoint: "http://mystack.com:5000/v2.0"
  openstack_management_url: "http://mycontroller:8774/v2/****************"
  username: "myuser"
  private_key_path: "/mykey.pem"
  key_name: "my-key"
  require_chef_omnibus: true
  image_ref: ubuntu1204
  flavor_ref: m1.testkitchen
  security_groups:
    - default
  floating_ip_pool: ext-net
  network_ref:
    - test-kitchen-network

provisioner: chef_zero

platforms:
  - name: ubuntu
    run_list:

suites:
  - name: uv_apache
    run_list: 
      - recipe[uv_apache::default]
      - recipe[minitest-handler]
    attributes:
      nfs:
        nfs_server_ip: '10.11.11.63'
  - name: uv_nfs_server
    run_list:
      - recipe[uv_nfs::default]
    attributes:
      nfs:
        network: '10.11.11.0/24'
    driver:
      floating_ip: '10.11.11.63'

Thank you

[hartmantis]

That sounds reasonable to me. I don't see any reason in the old pull requests why it was done in that order to begin with, and don't have a good argument for one order or the other.

Looks like the build failure is because of new checks in Rubocop rather than anything wrong with this change, so it's probably okay to override that. It should pass with something like a

PerceivedComplexity:
  Max: 10

in the .rubocop.yml. Thanks!

[hartmantis]

Nevermind. Went ahead and merged.