There are some short ideas about this bug, according to last meeting in IRC:
The problem reason:
<skraynev>>during replace we create second server and try to use old port
<skraynev>>but according to neutron model it's not possible
<skraynev>>to have two servers with same port
Some possible way to fix it:
......
<shardy>>--skraynev: should you be using the rebuild image update policy?
<shardy>>--instead of replacing the server?
.....
<stevebaker>>--we should be able to detach the port from the old server at some point in the update process
<mspreitz>>stevebaker: but timing is wrong, update makes new before deleting old, right?
<stevebaker>>--mspreitz: the port would have to be attached to the new post-create
<pas-ha>>--may be smth like post/pre-replace
.....
<stevebaker>>--or we deprecate the port resource and make it possible to specify all port details in the server networks list
<mspreitz>>yes, +1 on stevebaker's suggestion
<zaneb>>---stevebaker: that might also eliminate the opposite problem we also have, of Nova deleting the port from under us
<stevebaker>>--zaneb: it gets better, currently nova *doesn't* always delete ports that it creates, resulting in undeletable stacks!
<stevebaker>>--I was going to suggest a summit session on a rich server networks property
<zaneb>>---I'd like to have a summit session on a sensible API for neutron
<stevebaker>>--zaneb: and now they're talking managing port lifecycle in novaclient ;)
<zaneb>>---when it's easier to store state in the client(s) than your server, you know you've taken a wrong turn
<stevebaker>>--anyhoo, arosen has a change to fix the port deleting which is still in review
<zaneb>>---because nobody ever uses clients on different machines...
So As you can see some ways are possible: workarounds related with port detaching and attaching to new server or huge changes with deprecating whole resource....
Unfortunately we have not end solution, but it possibly will be discussed during mid-cycle meetup.
.
There are some short ideas about this bug, according to last meeting in IRC:
The problem reason:
<skraynev>>during replace we create second server and try to use old port
<skraynev>>but according to neutron model it's not possible
<skraynev>>to have two servers with same port
Some possible way to fix it: >--skraynev: should you be using the rebuild image update policy?
......
<shardy>
<shardy>>--instead of replacing the server?
..... >stevebaker: but timing is wrong, update makes new before deleting old, right? >--mspreitz: the port would have to be attached to the new post-create
<stevebaker>>--we should be able to detach the port from the old server at some point in the update process
<mspreitz>
<stevebaker>
<pas-ha>>--may be smth like post/pre-replace
..... >---stevebaker: that might also eliminate the opposite problem we also have, of Nova deleting the port from under us >--zaneb: it gets better, currently nova *doesn't* always delete ports that it creates, resulting in undeletable stacks! >--zaneb: and now they're talking managing port lifecycle in novaclient ;) >--anyhoo, arosen has a change to fix the port deleting which is still in review
<stevebaker>>--or we deprecate the port resource and make it possible to specify all port details in the server networks list
<mspreitz>>yes, +1 on stevebaker's suggestion
<zaneb>
<stevebaker>
<stevebaker>>--I was going to suggest a summit session on a rich server networks property
<zaneb>>---I'd like to have a summit session on a sensible API for neutron
<stevebaker>
<zaneb>>---when it's easier to store state in the client(s) than your server, you know you've taken a wrong turn
<stevebaker>
<zaneb>>---because nobody ever uses clients on different machines...
So As you can see some ways are possible: workarounds related with port detaching and attaching to new server or huge changes with deprecating whole resource....
Unfortunately we have not end solution, but it possibly will be discussed during mid-cycle meetup.
.