Comment 22 for bug 1741079

The issue was really introduced by this change https://review.openstack.org/#/c/308389/, which was intended to fix https://bugs.launchpad.net/neutron/+bug/1572593. Problem is that the fix is only a partial fix for the bug and it's a consequence of using four different OpenStack projects (Neutron, Nova, Designate and orchestration like Heat or Senlin) in the creation and deletion of the VM and its port:

1) When we have an orchestration layer, the ports are created before the VM is created. When the VM is deleted, Nova assumes correctly that it has to restore the port to its previous state, clearing the device_id, device_owner and dns_name. Nova does this using a neutron client with admin context, not the context of the user that is creating and deleting the VM

2) At the same time, in Designate the zones and recordsets are segregated by project / tenant. I cannot see or modify a zone that wasn't created by my project. That is why in Nova, when the VM is created, we update the port's dns_name using a neutron client with the context of the user creating the VM. Please look at this method: https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L1487

3) That is why the fix for the bug indicated above was incomplete: it should do something similar to what we do during VM creation. If dns_name is not none and the port's network has dns_domain set, it should assume that recordsets need to be removed from an external DNS service (Designate) and issue a second port update just to clear dns_name using a neutron client with the user's context

So the fix has to take place in Nova.

@Hang,

Are you going to file a bug in Nova and propose a fix?