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

Youcef Laribi Youcef.Laribi at eu.citrix.com
Fri Dec 7 20:19:42 UTC 2012


Hi Sam,

We discussed all of this before and at the last Summit at length :) Just like Quantum resources, we model all resources as top resources regardless of the arity of their relationship to each other. This also allows extensions can add more pools to a VIP (e.g. for L7 LB).

Thanks,
Youcef

From: Samuel Bercovici [mailto:SamuelB at Radware.com]
Sent: Friday, December 07, 2012 12:07 PM
To: OpenStack Development Mailing List; Youcef Laribi
Subject: RE: [openstack-dev] 答复: [Quantum][LBaaS] vip_id in pool creation API

Hi,

If vips and pools have 1:1 relationships, why do we need pools as first citizens?

Regards,
                -Sam.


From: Leon Cui [mailto:lcui at vmware.com]
Sent: Friday, December 07, 2012 2:25 AM
To: 'Youcef Laribi'
Cc: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
Subject: [openstack-dev] 答复: [Quantum][LBaaS] vip_id in pool creation API

Sounds good.  Thanks Youcef.

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

Hi Leon,

I’m assuming that when someone creates a pool and mentions a vip_id, we automatically also update the vip object with the new pool_id (to keep them in sync). But you are right, it’s simpler to have it read-only in the pool, and allow update only from the vip object. I’ll change the spec accordingly. I will also add the restriction that a pool can only be used in a vip if it is not already used by another vip (ie. Pools cannot be shared between vips, it’s 1:1).

Thanks
Youcef

From: Leon Cui [mailto:lcui at vmware.com]
Sent: Thursday, December 6, 2012 3:12 PM
To: Youcef Laribi
Cc: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
Subject: 答复: [Quantum][LBaaS] vip_id in pool creation API

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<mailto: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<mailto: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/20121207/fc716e19/attachment.html>


More information about the OpenStack-dev mailing list