floatingip[association] misses use case and fails on quota constraints
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Heat |
Confirmed
|
Medium
|
Unassigned |
Bug Description
There are three use cases for associating a FloatingIP with an instance:
1. Create and new FloatingIP (pull it from the main pool and add it to the tenant/project pool) and associate it with an instance. This is currently handled by OS::Neutron:
2. Associate a FloatingIP that is already in the tenant/project pool, is currently unused, _and_ the uuid of the FloatingIP is known at stack-create time. This functionality is currently handled by OS::Neutron:
3. Associate a FloatingIP that is already in the tenant/project pool, is currently unused, _and_ the uuid is unknown or the user does not care - ie. just pick one of the free FloatingIP's arbitrarily and assign it to the VM instance.
The problem with not having use case three results in a FloatingIP association failure under the following circumstances. I currently have users/customers experiencing this in a production deployment.
1. The user has a "full quota" of FloatingIP's in their tenant/project pool - ie. they have a quota of 10 FloatingIP's and have 10 created, but <=10 associated. (OS::Neutron:
2. The user doesn't care what FloatingIP is assigned. (but, floatingip_id is currently required by OS::Neutron:
There are two possible solutions here:
1. Have OS::Neutron:
2. Make floatingip_id optional in OS::Neutron:
Up front looking for validation, opinions and guidance here.
Once discussion has happened I can submit a patch if necessary - I don't want to go in the wrong direction.
Changed in heat: | |
assignee: | nobody → Sean Lynn (trad511) |
Changed in heat: | |
status: | New → Triaged |
importance: | Undecided → Medium |
Changed in heat: | |
assignee: | Sean Lynn (trad511) → Deliang Fan (vanderliang) |
status: | Triaged → In Progress |
Changed in heat: | |
assignee: | Deliang Fan (vanderliang) → nobody |
status: | In Progress → Confirmed |
Changed in heat: | |
milestone: | none → no-priority-tag-bugs |
As an extra comment our users don't have the ability to floatingip-delete due to floatingIP firewall/security restrictions in the company - ie. one customer inheriting an floatingip from another customer where firewall rules have been plumbed out against the floatingIP. Even without this restriction people will run into this though.