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::FloatingIP.
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::FloatingIPAssociation.
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::FloatingIP uses floatingip_create which fails because the user is "over quota").
2. The user doesn't care what FloatingIP is assigned. (but, floatingip_id is currently required by OS::Neutron::FloatingIPAssociation)
There are two possible solutions here:
1. Have OS::Neutron::FloatingIP check and select an unused FloatingIP from the tenant/project's local "pool" if available, otherwise do a create. Personal opinion is that docs, example templates lead users in this direction, but it's a mis-use of the the resource. Note that by example templates look at this and most others in the repo: https://github.com/openstack/heat-templates/blob/master/hot/servers_in_existing_neutron_net.yaml
2. Make floatingip_id optional in OS::Neutron::FloatingIPAssociation and add logic to check for and pull a FloatingIP from the user's internal pool. Would require updates to docs (to lead people in the right direction), templates, a few more lines in ./heat/engine/resources/openstack/neutron/floatingip.py and a new test. I think this might be a bit of "expected behavior" change for users who are reading through posted heat templates in the repo.
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.
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.