Open Stack

On 22 July 2016 at 14:54, Andrey Volkov <avolkov at mirantis.com> wrote:
> Hi, nova and neutron teams,
>
> While booting new instance nova requests port for that instance in the
> neutron.
> It's possible to have a situation when neutron doesn't response due timeout
> or connection break and nova retries port creation. It definitely results in
> ports duplication for instance [1].
>
> To solve this issue different methods can be applied:
> - Transactional port creating in neutron (when it's possible to rollback if
> the client doesn't accept the answer).
> - Idempotent port creation (when the client provides some id and server does
> get_or_create on this id).
> - Getting port on the client before next retry attempt (idempotent port
> creation on the client side).
>
> Questions to community:
> - Am I right with my thoughts? Does the problem exist? Maybe there is tool
> already can solve it?
> - Which method is better to apply to solve the problem if it exists?
>
> [1] https://bugs.launchpad.net/nova/+bug/1603909

So I am currently taking a close look at Nova and Neutron interactions
to eliminate these kinds of things.

I hope to work with Neutron to evolve our APIs to try and eliminate
this kind of thing, more systematically. I have promised to work with
Nova and Neutron to get a plan together for the next summit.

I am super happy you have tracked down one of failure modes here.

If we hit a port create timeout, it possible Neutron has created the
port, but Nova never gets the port uuid, so doesn't delete that port
during its cleanup.

I think we probably need to list the ports in neutron when working out
what to delete, to make sure we don't leak ports due to timeouts.

Thanks,
johnthetubaguy