Open Stack

The Core API (for Grizzly) supports the simple use cases that can be easily implemented by all vendors.

We had a long consultation period around the API spec to give a chance to everyone to provide their input, and now it is more or less locked, apart from small changes to facilitate implementation for Grizzly release. Extra use cases (multiple pools per VIP, multiple VIPs per pool, member stats, L7 rules, etc.) can always be implemented as extensions for now by vendors who wish to do so, and in future releases could be folded into Core if we have consensus.

Having said this, if the rest of the team feel we should add the use case of “multiple vips sharing the same pool” to the resource model and API, then I can amend the API spec accordingly. I would note though, that this would complicate vip scheduling, since 2 or more vips sharing the same pool, would need to be placed on the same device. The vip stats would also be less meaningful and we might need to move to per-pool stats.

Thanks
Youcef

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

Hi,

I think that the most common use case is using a pool with multiple vip services (ex: 1.1.1.1:80 and 1.1.1.1:443)
In the proposed model, if we have the same group of nodes participating in multiple say services on port 80 and 443, we need to specify two vips (since we did not separate between the IP address and the port) and will need to create two pools.
I would expect us to be able to reuse the pool.

What am I missing?

Regards,
                -Sam.




From: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]
Sent: Friday, December 07, 2012 10:20 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] 答复: [Quantum][LBaaS] vip_id in pool creation API

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/8f2a87b2/attachment.html>