[openstack-dev] [Heat][Nova][Neutron]Detach interface will delete the port

2014-04-17 Thread Huangtianhua
Hi all,

Port is a resource define in Heat. And heat support the actions: create a 
port/delete a port/attach to a server/detach from a server.

But we can't re-attach a port which once be detached.

-
There is such a scenario:


1.   Create a stack with a template:

..

resources:

  my_instance:

type: OS::Nova::Server

properties:

  image: { get_param: ImageId }

  flavor: { get_param: InstanceType }

  networks: [ { port : {Ref: instacne_port}}]



  instacne_port:

type: OS::Neutron::Port

properties:

  network_id: { get_param: Network }



Heat will create a port and a server, and attach the port to the server.



2.   I want to attach the port the another server, so I update the stack 
with a new template:

..

resources:

  my_instance:

type: OS::Nova::Server

properties:

  image: { get_param: ImageId }

  flavor: { get_param: InstanceType }

  my_instance2:

type: OS::Nova::Server

properties:

  image: { get_param: ImageId }

  flavor: { get_param: InstanceType }

  networks: [ { port : {Ref: instacne_port}}]



  instacne_port:

type: OS::Neutron::Port

properties:

  network_id: { get_param: Network }



Heat will invoke the nova detach_interface API to detach the interface, and 
wanted to attach the port to the new server.

But the stack update is failed , and there is an 404 portId not find error 
raised on neutron. Because the port has been deleted while detaching.



There is no real detach api for heat to invoke. The nova API detach_interface 
will invoke the Neutron API delete_port, and then the port will be deleted.
   
---

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.

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

What do you think about?

Cheers

Tianhua



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat][Nova][Neutron]Detach interface will delete the port

2014-04-17 Thread Sergey Kraynev
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.

Regards,
Sergey.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat][Nova][Neutron]Detach interface will delete the port

2014-04-17 Thread Sergey Kraynev
There is interesting patch on review
https://review.openstack.org/#/c/77043/15.
I suppose that it's related with discussed problems. Possibly we should
wait when it will be merged and then check mentioned use-cases.

Regards,
Sergey.


On 17 April 2014 12:18, Huangtianhua huangtian...@huawei.com wrote:





 *发件人:* Sergey Kraynev [mailto:skray...@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 doJ

 Regards,

 Sergey.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev