search

cloudfoundry / bosh-openstack-cpi-release

BOSH OpenStack CPI
Apache License 2.0
36 stars 59 forks source link

`Fixed IP address ... is already in use on instance .).` when downgrading neutron → nova #116

Closed cunnie closed 3 years ago

cunnie commented 6 years ago

Hi Marco & Everyone,

This is not something you need to fix; it's an FYI, something we came across during one of our failed tests:

  Deleting VM '29abd612-bf89-4a59-909d-0bc5b80d1273'... Finished (00:00:12)
  Creating VM for instance 'bosh/0' from stemcell 'fee5f147-bd3f-405c-844f-6cdbda58ddb2'... Failed (00:00:02)
Failed deploying (00:00:37)

Stopping registry... Finished (00:00:00)
Cleaning up rendered CPI jobs... Finished (00:00:00)

Deploying:
  Creating instance 'bosh/0':
    Creating VM:
      Creating vm with stemcell cid 'fee5f147-bd3f-405c-844f-6cdbda58ddb2':
        CPI 'create_vm' method responded with error: CmdError{"type":"Bosh::Clouds::CloudError","message":"OpenStack API Bad Request (Fixed IP address 192.168.103.13 is already in use on instance >

At that point you either need to set the networking model back to neutron & redeploy or free up the port with the OpenStack CLI & redeploy with the nova networking model:

openstack port list | grep BOSH-IP-ADDRESS
openstack port delete PORT-ID
voelzmo commented 6 years ago

Hey Brian,

Thanks for documenting this – I wasn't aware that switching from neutron to nova-networking was creating such issue. Unfortunately, I'm not really sure what we could do about this, except documenting it. Did you encounter this during tests? If not, what was the reason for switching from neutron to nova-networking? My hope was that nova-networking would only be used by people whose OpenStack doesn't offer neutron.

Warm regards Marco

cunnie commented 6 years ago

Did you encounter this during tests?

Yes, it was our CI that caught this. We did a CPI bump on a bunch of versions of our application, Ops Manager (1.11, 1.12, 2.0, and 2.1). On version 1.11 we never exposed the use_nova_networking option, but on later versions we exposed it. We also made a conscious decision to stick to nova networking in our CI.

The CPI bump changed the default networking from nova to neutron. Our version 1.11 never exposed that option, so it was upgraded to neutron. But then our upgrade (to 1.12) Concourse job ran, and that job deliberately set use_nova_networking to true, which had the effect of downgrading the OpenStack backend to nova, and that's when we ran into the error.

My hope was that nova-networking would only be used by people whose OpenStack doesn't offer neutron.

I share that hope. I made the case that we should switch our CI from nova to neutron, mentioning that nova was a deprecated OpenStack backend, but the PM didn't feel comfortable with that move, and opted to stick with nova, so I re-engineered our code to silently set use_nova_networking to true on version 1.11 of our codebase. I've since rotated to a different team (PWS).

See you the next time you're out here,

—Brian

voelzmo commented 6 years ago

Alright, thanks Brian for the explanation. I'm going to leave this one around here for documenting the behavior.