make net_id configurable in micro_bosh.yml (Openstack)

[grenzr]

I'm trying to boot a microbosh in Openstack, and it would be nice if it were possible to configure (perhaps as a switch on the bosh-bootstrap command line) net_id in the generated micro_bosh.yml file.

Reason is Openstack is incorrectly assigning an ip from the floating ip range, and then bosh micro deploy fails to assign the floating ip later in the bosh-bootstrap execution.

Deploy Micro BOSH
  unpacking stemcell (00:00:02)
  uploading stemcell (00:01:40)
Creating VM from...                 |oooo                    | 2/11 00:03:10  ETA: 00:06:15/home/developer/.rbenv/versions/1.9.3-p392/lib/ruby/gems/1.9.1/gems/bosh_openstack_cpi-1.5.0.pre.1154/lib/cloud/openstack/helpers.rb:20:in
`cloud_error': OpenStack API Bad Request (Error. Unable to associate floating ip). Check task debug log for details. (Bosh::Clouds::CloudError)
        from /home/developer/.rbenv/versions/1.9.3-p392/lib/ruby/gems/1.9.1/gems/bosh_openstack_cpi-1.5.0.pre.1154/lib/cloud/openstack/helpers.rb:43:in `rescue in with_openstack'
        from /home/developer/.rbenv/versions/1.9.3-p392/lib/ruby/gems/1.9.1/gems/bosh_openstack_cpi-1.5.0.pre.1154/lib/cloud/openstack/helpers.rb:25:in `with_openstack'
        from /home/developer/.rbenv/versions/1.9.3-p392/lib/ruby/gems/1.9.1/gems/bosh_openstack_cpi-1.5.0.pre.1154/lib/cloud/openstack/vip_network.rb:32:in `configure'
        from /home/developer/.rbenv/versions/1.9.3-p392/lib/ruby/gems/1.9.1/gems/bosh_openstack_cpi-1.5.0.pre.1154/lib/cloud/openstack/network_configurator.rb:72:in `configure'

Fixing a net_id in micro_bosh.yml as follows resolves my problem:

network:
  type: dynamic
  vip: 10.95.192.20
  cloud_properties:
    net_id: d66e02e4-61a3-4f2d-84da-ddc5e5982b7e

[drnic]

Ryan, do you have any ideas on how we might make the UX nice? Can bosh-bootstrap detect if a user will want to provide a net_id in advance? Is there something in their OpenStack API that we can poll - a list of net_ids?

Nic

[grenzr]

Hey Nic,

I haven't tested this, but thought I'd throw you a bone before I disappear for the evening:

curl -d '{"auth": {"tenantName": "xxx", "passwordCredentials":{"username": "xxx", "password": "xxx"}}}' -H "Content-type: application/json" http://xxx.xxx.xxx.xxx:35357/v2.0/tokens

Use this to get yourself a token from Keystone, and then:

curl http://<API_ip>:9696/v2.0/networks -X GET -H "X-Auth-Token: <big_massive_token>" | python -m json.tool

Will give you a nice list of networks. id property = net_id :)

I like the idea of listing the possible networks and selecting from one (or none to leave it undefined in the manifest)

Ryan

[frodenas]

As we're using fog, we can check if net = Fog::Network[:openstack] doesn't fail, that would mean that OpenStack is using Neutron. Then we can easily retrieve the network list using fog method 'net.networks'.

[drnic]

@frodenas @grenzr do you know how to connection.addresses.create when the floating IPs are attached to Neutron networks?

[frodenas]

@drnic I believe is the same api call (don't have a Neutron env right now). OpenStack will do the work in the backstage whatever networking component you're using.

[duritong]

@drnic I had the same issue with the inception server and could quick-fix it with the following create call:

connection.addresses.create(:pool => 'pool_name')

I will probably soon have to do the same with bosh

[drnic]

Work has started during today. See https://github.com/cloudfoundry-community/cyoi/pull/13

[drnic]

PR for this work is in https://github.com/cloudfoundry-community/bosh-bootstrap/pull/263

[drnic]

v0.14 has support for openstack neutron & aws vpc now