[openstack-dev] [quantum][LBaaS] need to do corresponding changes in LBaaS API doc

Youcef Laribi Youcef.Laribi at eu.citrix.com
Wed Dec 26 23:07:35 UTC 2012


Oleg,

In this case, we are not creating resources. The pool has already been created and we know to which tenant it belongs. Same thing for health monitor. So what does specifying a tenant Id accomplish in this call (associating a health monitor with a pool)?

Thanks
Youcef

On Dec 25, 2012, at 0:20, "Oleg Bondarev" <obondarev at mirantis.com<mailto:obondarev at mirantis.com>> wrote:

Hi Youcef,

I think that tenant_id should be present in every resource and sub-resource as it is verified by framework for any API call - so for creating a sub-resource too.
I ‘ve also looked through the updated API doc and still think we should add “health_monitors” to the list of updatable attributes of a pool. What do you think?

Thanks,
Oleg

From: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]
Sent: Tuesday, December 25, 2012 7:54 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [quantum][LBaaS] need to do corresponding changes in LBaaS API doc

Thanks Oleg. For associating a health monitor with pool with this call.

POST pools/<pool_id>/health_monitors
{
                ‘id’: <health_monitor_id>,
                ‘tenant_id’: <tenant_id>
}

I believe the “tenant_id” in the request body is not needed, since both the pool and the health monitor are already created. What do you think?

Youcef



From: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]
Sent: Saturday, December 22, 2012 5:29 AM
To: 'OpenStack Development Mailing List'
Subject: Re: [openstack-dev] [quantum][LBaaS] need to do corresponding changes in LBaaS API doc

Hi Oleg,

Thanks, I have reviewed these, and require some clarification from you.


-          add default values for fields not specified while VIP creation

Do you mean “description” and “connection_limit” fields? For “description”, the default value if not specified by the user is an empty string, while “connection_limit” if not specified by the user is not used (internally and in DB, you can store it as “-1” meaning there is no connection limit).
[obondarev] Agree


-          add “description” and “connection_limit” fields with default values to the response of Create VIP Example

In the response, if description is an empty string and if “connection_limit” is set to -1, we do not return them, as it means the user has not set these, and they have got a NULL value.
[obondarev] Agree


-          add “lb_method” field to the request of Create Pool Example as it is required

Yes, good catch! I’ll add this.


-          remove “members” filed from the request of Create Pool Example

-          add “health_monitors” to the list of updatable attributes of a pool

-          remove “List all Members of a specific Pool” and “List Health Monitors associated with a Pool” REST calls from the API

Yes, since we have agreed now on an approach for dealing with sub-resources, I can now update the spec.


-          add “pool_id” to the must list when creating a member
Yep.


-          add appropriate values to the request of Associate Health Monitors with a Pool Example

I thought that associating/dissociating pools and health_monitors is now done when creating or updating a pool (by specification a collection attribute). Can you clarify for me what the current implementation does?
[obondarev] It’s true but we also still have an opportunity to associate/disassociate monitors with pools using sub-resource concept:
POST pools/<pool_id>/health_monitors {body}
DELETE pools/<pool_id>/health_monitors/<health_monitor_id>
Where body is:
{
                ‘id’: <health_monitor_id>,
                ‘tenant_id’: <tenant_id>
}
- to add one monitor to a pool – this avoids user from doing two roundtrips where he needs first to do GET and then PUT on a pool resource.

Thanks
Youcef

From: Oleg Bondarev [mailto:obondarev at mirantis.com]<mailto:[mailto:obondarev at mirantis.com]>
Sent: Thursday, December 20, 2012 1:49 AM
To: Youcef Laribi; 'OpenStack Development Mailing List'
Subject: RE: [openstack-dev][quantum][LBaaS] need to do corresponding changes in LBaaS API doc

Sure Youcef, here’s the list of updates:


-          add default values for fields not specified while VIP creation

-          add “description” and “connection_limit” fields with default values to the response of Create VIP Example

-          add “lb_method” field to the request of Create Pool Example as it is required

-          remove “members” filed from the request of Create Pool Example

-          add “health_monitors” to the list of updatable attributes of a pool

-          remove “List all Members of a specific Pool” and “List Health Monitors associated with a Pool” REST calls from the API

-          add “pool_id” to the must list when creating a member

-          add appropriate values to the request of Associate Health Monitors with a Pool Example

Thanks,
Oleg
From: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]
Sent: Wednesday, December 19, 2012 11:42 PM
To: Oleg Bondarev; OpenStack Development Mailing List
Subject: RE: [openstack-dev][quantum][LBaaS] need to do carresponding changes in LBaaS API doc

Oleg,

Can you outline what those changes are?

Thanks,
Youcef

From: Oleg Bondarev [mailto:obondarev at mirantis.com]<mailto:[mailto:obondarev at mirantis.com]>
Sent: Wednesday, December 19, 2012 5:39 AM
To: Youcef Laribi; OpenStack Development Mailing List
Subject: [openstack-dev][quantum][LBaaS] need to do carresponding changes in LBaaS API doc

Hi Youcef,

Now after LBaaS API extension patch was merged we need to do several corresponding changes in the API doc.
I can do it if you provide me rights on editing the page (http://wiki.openstack.org/Quantum/LBaaS/API_1.0).

Thanks,
Oleg
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121226/c108917e/attachment.html>


More information about the OpenStack-dev mailing list