Open Stack

发件人: Sergey Kraynev [mailto:skraynev at mirantis.com]
发送时间: 2014年4月17日 15:35
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [Heat][Nova][Neutron]Detach interface will delete the port

Hello Huang.

You are right, that this problem is presented in networks update for OS::Nova::Server. I have known about it, and I wanted to discuss it with Steve Baker, but possibly forgot to do it. Thank you, that you raise this thread.

About issue.

The cause why it happens is simple: when nova calls detach_interface,  port will be detached  and deleted at all.


I think there are two solutions:
First:
Heat get the port information before to “detach”, and to create the port again before to “attach”.

But I think it looks ugly and will increase risk failure for re-create.

I agree that it's not useful solution. This approach has a lot of bad sides and one of them :
 - if you update only server, your other resources should stay without changes, but in this case port will be recreated. (so it will be new different resource)

Second:
Neutron provide a detach_port api to nova, so that nova provide the real “detach” not “delete” to heat.


I have told with folk from neutron team and they told me that neutron does not have such api and it's not possible to do this thing.

So I think, that problem should be solved in nova. F.e. will be good to provide detach_interface command with additional flag delete_port=True. (some kind of soft detach).
In this case we could use existing port after detaching.

------
       We discuss it in our team, it’s relate to server_delete also, if we update the stack just to delete the server, the port will be deleted too.
So if we want to solve the problem in nova, the process of delete instance need to modify. May be need to modify the server_delete api to add a flag too.
     But this change seems provide to heat only. And may be it’s not easy to do☺
Regards,
Sergey.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140417/f3e77c6c/attachment.html>