Delete is possible of an in-use port

[Gavin B]

Running in a quantum-enabled devstack.

Using Quantum, I created a network and subnet and then created a VM that used the network.

I then deleted the port used by the VM - no error, and I end up
getting a VM without an address :

ubuntu at az3devstackvm2:/opt/stack/tempest2/tempest/tests/network$ nova list
+--------------------------------------+-----------------------+--------+----------+
| ID | Name | Status | Networks |
+--------------------------------------+-----------------------+--------+----------+
| e43ec1a6-9499-4a7f-bbd0-fbecf6f3c115 | server-negtest-322040 | ACTIVE | |
+--------------------------------------+-----------------------+--------+----------+

So far I've not found a way to re-attach the VM to my network.

I'm unclear is this is a bug or a feature - however deleting an in-use network or subnet is trapped, so
I think this ought to be so also.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/21520

[Aaron Rosen (arosen)]

Doesn't this do it: quantum port-create net --device_id=<nova instance_id>

[dan wendlandt (danwent)]

Aaron, I don't think that would be sufficient, as Nova associates the
quantum port-uuid with a vNIC when it is attached to the switch (e.g.,
OVS).

As a result, the user would have to be able to create another quantum port
with the exact same UUID, which is not possible.

The v1 version of the Quantum API actually had an explicit notion of a port
uuid which was separate from the "attachment-id", which represented the
item plugged into the port (e.g., the vNIC). However with v2, we moved
toward a model where there were not separate IDs for both vNIC and port,
but rather one ID. The consequence though is that if you delete the port,
you also effectivelly delete the VIF (while it will still show up in the VM
as a device, it is dead to the world as far as connectivity).

Dan

On Sun, Feb 10, 2013 at 11:56 PM, Aaron Rosen <email address hidden> wrote:

> Doesn't this do it: quantum port-create net --device_id=<nova
> instance_id>
>
> --
> You received this bug notification because you are a member of Netstack
> Core Developers, which is subscribed to quantum.
> https://bugs.launchpad.net/bugs/1119409
>
> Title:
> Delete is possible of an in-use port
>
> Status in OpenStack Quantum (virtual network service):
> In Progress
>
> Bug description:
>
> Running in a quantum-enabled devstack.
>
> Using Quantum, I created a network and subnet and then created a VM
> that used the network.
>
> I then deleted the port used by the VM - no error, and I end up
> getting a VM without an address :
>
> ubuntu at az3devstackvm2:/opt/stack/tempest2/tempest/tests/network$ nova
> list
>
> +--------------------------------------+-----------------------+--------+----------+
> | ID | Name | Status
> | Networks |
>
> +--------------------------------------+-----------------------+--------+----------+
> | e43ec1a6-9499-4a7f-bbd0-fbecf6f3c115 | server-negtest-322040 | ACTIVE
> | |
>
> +--------------------------------------+-----------------------+--------+----------+
>
> So far I've not found a way to re-attach the VM to my network.
>
> I'm unclear is this is a bug or a feature - however deleting an in-use
> network or subnet is trapped, so
> I think this ought to be so also.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/quantum/+bug/1119409/+subscriptions
>

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Ante Karamatić (ivoks)]

c/p from gerrit comment:

Could we rearrange workflow so that nova would:

delete VM
free/unassign port/IP
delete port/IP

Second step would just update the row, allowing the IP to be deleted.

Another option would be to 'force' delete the port, when request comes from nova. I'm just not sure how we could distinguish nova from other clients.

[dan wendlandt (danwent)]

I don't think it makes sense to make Nova make two different API calls.

In general, notions like "force" are useful in CLIs and GUIs, but should not be part of an API (since an API is a programming, not a user interface). I'm all for adding a notion of force to the Quantum CLI and to Horizon (I think i mentioned this in my mail to the ML)

[Mark McClain (markmcclain)]

Changed Quantum status and removing the milestone. The Quantum core team believes that the server should continue to allow deletes when these fields are set. The preferred alternative is additional checks in Horizon and/or the CLI to block deletion when the port is in-use.

[Akihiro Motoki (amotoki)]

In Horizon, non-admin user is not allowed to create/delete ports now. I think It is a reasonable guard to avoid deleting of ports accidentally. In admin panel, admin can delete a port even if a port is attached. It can be improved in the future.

[Armando Migliaccio (armando-migliaccio)]

This bug is > 172 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.

If the bug is still valid, then update the bug status.

[Launchpad Janitor (janitor)]

[Expired for python-neutronclient because there has been no activity for 60 days.]