port disappears if the instance goes in error

I think we will have to add a new field into port to show if it is created by nova or not.
I suggest to do it in the extension portbinding extension.

I thought about it, and adding metadata (i.e. bindings) to ports can turn out to be useful in a number of contexts, like the ones reported here:

https://bugs.launchpad.net/neutron/+bug/1158684
https://answers.launchpad.net/nova/+question/230868

However, in this specific case where the compute node fails to spawn an instance, it is enough to allow the compute clean-up logic to dispose of the port only if it was not created explicitly (as in I don't see the need to use the port binding extension).

So IMO, I could address this one in a small, fairly contained patch, and deal with the others in the way you suggested.

Thoughts?

is it worth backporting it?

Reviewed: https://review.openstack.org/36354
Committed: http://github.com/openstack/nova/commit/a141206e9dfd31955b9b31d9e5a7f73bbd8510ca
Submitter: Jenkins
Branch: master

commit a141206e9dfd31955b9b31d9e5a7f73bbd8510ca
Author: armando-migliaccio <email address hidden>
Date: Mon Jul 8 19:47:34 2013 -0700

    Avoid deleting user-provided Neutron ports if VM spawn fails

    If the VM boot fails, resources like Neutron ports are destroyed.
    This is particularly bad if the failure is transient and a
    rescheduling attempt is made. In this case the port no longer exist
    and the failure becomes self-inflicted. To avoid this, during the
    deletion of VM resources, we look at the requested_networks passed
    by the user: if they contain port ids, we skip the destruction.

    An optional parameter is added to RPC method deallocate_for_instance.
    RPC Network API is bumped to 1.10 to reflect this change, but the
    change is backward compatible.

    Fixes bug #1195490

    Change-Id: Iade232267c58ae2cf3966829e660d3298070a3bf