provider/openstack Proposal: drop floating_ip from instances

[Fodoj]

From documentation:

Floating IPs can be associated in one of two ways:

You can specify a Floating IP address by using the top-level floating_ip attribute. This floating IP will be associated with either the network defined in the first network block or the default network if no network blocks are defined.

You can specify a Floating IP address by using the floating_ip attribute defined in the network block. Each network block can have its own floating IP address.

There is a major problem with top-level floating_ip: it does not react to changes in actual infrastructure.

Its easy to check it: create an instance with top-level FIP, then deassociate this FIP in Nova and then re-run terraform. Terraform won't notice any changes and will behave as if FIP is still associated with this instance.

There are two ways to fix it:

1. Add some check in the code, that will loop through instance addresses and try to find FIP in it. If its not there - try to re-associate
2. Drop top-level FIP completely

I believe dropping it completely is a way to go. FIP is always associated with one of networks anyways, and having it top level is both confusing and adds weird bugs.

[Fodoj]

Of course, one of benefits to using top level at the moment is the fact that it doesnt have the same bug, as network. Luckily, I fixed this bug in this PR: #6579

[jtopjian]

@Fodoj Thank you for your input.

I agree with you that having two ways of specifying a floating IP can be confusing. The openstack_compute_instance_v2 resource can be quite unwieldy at times due to the numerous use-cases it has to account for.

As discussed previously, the top-level floating IP used to be the only way to specify a floating IP to an instance. The caveat, as mentioned in the docs you posted, is that it will only attach to the first specified network. Those docs also mention one very important piece:

or the default network if no network blocks are defined.

The public cloud providers in Terraform have it easy ( 😏 ) because there's only one way to use the cloud service. OpenStack environments can differ from site to site. One of those differences is the inability for users to define networks. It sounds crazy, but those types of environments exist and I'd hate for Terraform to be useless to a subset of users because while Terraform could have accounted for the use-case, it didn't. This is why I try to account for all use-cases. It gets messy and it can suck at times, but it's also a fun challenge.

I sympathize with any frustration you have with usability. In hindsight, maybe there could have been a better way to implement the per-network floating IPs:

• a top-level floating_ip_network_id argument
• a floating_ip block
• removing floating IPs from instances entirely and only using the openstack_compute_floatingip_v2``andopenstack_networking_floatingip_v2` resources

Unfortunately in this case, we can't just drop this functionality, though. I'm open to alternative ways of implementing this as well as patches to fix issues like the one you described (there are other pieces that have had the same issue you describe - we didn't just drop those).

I'm going to go ahead and close this, but please feel free to re-open if you feel very strongly about the removal and we can discuss further.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.