On 22 July 2016 at 14:54, Andrey Volkov <avol...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
