(我使用openstack4j通过REST API与OpenStack通信)

我想重用一些在我的租户中分配的未分配的浮动IP(分配给新配置的服务器).但是,似乎addFloatingIp操作在分配未使用的浮动IP和从服务器到服务器重新分配它之间没有区别.

我想自动化这个过程,但我害怕跟随竞争条件：一个客户端检查特定的IP是免费的,在它设法将它与服务器A关联之前,其他客户端将它与服务器B关联.从第二个客户端的角度来看,成功关联后,可以在以后的任何时候删除关联的浮动IP.

有没有更好的方法？

最佳答案 可能的解决方法是：

>仅删除并创建浮动IP.正如你所说,这是首选方式.通过小型VM可以从内部定期清理不再使用的浮动IP.但应优先考虑API客户端从外部清理.因此,每个客户都应该集成这个功能,但是必须注意这是用户的意图,至少它们会丢失一些重要的东西.示例：用于删除VM的Web UI可能会询问是否还应删除关联的浮动VM. Openstack Heat(通过模板进行编排)会自动执行此操作. CLI客户端可以在删除VM后删除已释放的资源.
>使用支持同步的东西进行协调.示例：具有事务支持的etcd,数据库(SQL或非数据库),可确保传递完成一次的队列(例如OpenStack Zaqar及其声明功能).
>使用时间流逝进行同步：读取,更改,等待特定时间,最后再次阅读以检查是否有人覆盖了更改.如果此更改耗时太长,请在特定等待时间之前中止.如果更改被覆盖,则使用不同的浮动ip重试.这很难做到,因为有许多极端情况,特别是很快就能正确中止,这可能会导致失败.例如,如果不是每个更改通过的位置确保不会发生这种情况,则高负载可能会使更改成功.

其他OpenStack API也有同样的问题,例如updating security groups.通常可以通过向API添加修订计数器来避免这种情况,例如kubernetes (resourceVersion from ObjectMeta)和etcd (modifiedIndex in v2,v3中的mod_revision).

即使对于实现无种族更改选项的API,大多数人类用户界面也可能仅用于种族检测而不是避免,因为用户界面告诉他们有种族和覆盖的内容优先于要求他们重试的内容.每次比赛发生时他们的行动.