（我使用openstack4j通过REST API与OpenStack对话）
我想重用在我的租户中分配的一些未分配的浮动IP（分配给新配置的服务器）。然而，addFloatingIp操作似乎在分配未使用的浮动IP和将其从服务器重新分配到服务器之间没有区别。
我想自动化这个过程，但我担心以下竞争条件：一个客户端检查特定的IP是否可用，在它设法将其与服务器A关联之前，另一个客户端将其与server B关联。从第二个客户端的角度来看，在成功关联后，可以在稍后的任何时候删除关联的浮动IP。
有更好的方法吗？
可能的解决方法有：
- 仅删除和创建浮动IP。正如你所说，这是首选方式。小型虚拟机可以定期从内部清理不再使用的浮动IP。但最好是由API客户端从外部进行清理。因此，每个客户端都应该集成此功能，但必须注意这是用户想要的，至少他们会丢失一些重要的东西。示例：用于删除虚拟机的web UI可能会询问它是否也应该删除关联的浮动虚拟机。Openstack Heat（通过模板编排）会自动执行此操作。CLI客户端可以在删除VM后提供删除释放的资源
- 使用支持同步的东西进行协调。示例：etcd，具有事务支持的数据库（无论是否为SQL），可以确保只完成一次交付的队列（例如具有声明功能的OpenStack Zaqar）
- 利用时间的推移进行同步：阅读、更改、等待特定的时间，最后再次阅读以检查是否没有人覆盖更改。如果此更改花费的时间太长，则在特定等待时间之前中止。如果更改被覆盖，请使用其他浮动ip重试。这很难纠正，因为有很多角落的情况，尤其是在足够快地正确中止的情况下，可能会导致失败。例如，如果不是每个地方都能确保更改不会发生，那么高负载可能会使更改在中止后很长一段时间内成功
其他OpenStack API也有同样的问题，例如更新安全组。通常，可以通过向API添加修订计数器来避免这种情况，例如kubernetes（ObjectMeta中的resourceVersion）和etcd（v2中的modifiedIndex，v3中的mod_revision）这样做。
即使对于实现无种族更改选项的API，大多数人类UI也可能只将其用于种族检测，而不是避免，因为告诉他们有种族的UI，它覆盖的内容比每次种族发生时要求他们重试操作的UI更可取。
有问题的挑战涉及使用（现已弃用）计算服务的浮动IP扩展，该扩展将浮动IP分配分为两个步骤：分配（/os-floating-ips端点）和分配（addFloatingIp服务器操作）。
目前支持的方法是通过中子服务操作浮动IP，该服务允许在一个请求中创建和关联浮动IP（POST到/v2.0/floatingips）。至少在理论上，这消除了希望重用浮动IP的客户端同时需要某个其他客户端关联的可能性。如果所有客户端都同意使用这种浮动IP分配模式，则无关联的浮动IP可以安全地作为悬挂实体进行处理。