[openstack-dev] 答复: [Quantum][LBaaS] vip_id in pool creation API

Leon Cui lcui at vmware.com
Thu Dec 6 23:12:24 UTC 2012


Hi Youcef,

That’s exactly what I suggest that don’t place a “vip_id” inside pool
creation payload.  In this way, “vip_id” is a ready-only property in
pool and we can avoid the case that you mentioned.

Currently API spec said that “vip_id” could be provided during pool
creation (POST) call. It potentially allows someone to create a pool to be
associated with a VIP which still think is associated with another pool.



Correct me if my statement is wrong.  thanks



Thanks

Leon

发件人: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]
发送时间: 2012年12月5日 11:56
收件人: Leon Cui
抄送: openstack-dev at lists.openstack.org
主题: RE: [Quantum][LBaaS] vip_id in pool creation API



Hi Leon,



The reason the spec said this is to ensure that the information in the VIP
(which pool_id is used by the VIP) and the information in the pool (to
which VIP the pool belongs, if it belongs to one), never get out-of-sync.
If we allowed separate updates, then someone can update the pool to be
associated with a new VIP, but the old VIP still thinks the pool is
associated with it.



Thanks,

Youcef







From: Leon Cui [mailto:lcui at vmware.com]
Sent: Wednesday, December 5, 2012 10:24 AM
To: Youcef Laribi
Cc: openstack-dev at lists.openstack.org
Subject: [Quantum][LBaaS] vip_id in pool creation API



Hi Youcef,

In Create_Pool API, the spec says “Optionally, you can also assign the
pool to a vip during creation time, by specifying the vip_id attribute.”.
I don’t think we should allow user to do it because it means that it will
modify the “pool_id” of a VIP in an implicitly way.  I suggest that
don’t allow user to provide vip_id during pool creation api. User can
always to update the VIP by given a different pool_id.



What do you think?



Thanks

Leon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121206/1f61c3af/attachment.html>


More information about the OpenStack-dev mailing list