Open Stack

Hi Peter,

Let me try to answer your comments.


1)      API Schemas

·         What are your thoughts about schemas?

·         Do we envision any schemas do define the request / response bodies e.g. JSON schema?

·         We require some way to define JSON payloads OR is the Wiki the definitive source? ( e.g. in Atlas you had XSDs )

Currently OpenStack projects are not uniform with this respect. The following projects do seem to have XSDs:

·         Compute: https://github.com/openstack/compute-api/tree/master/openstack-compute-api-2/src/xsd

·         Keystone: https://github.com/openstack/identity-api/tree/master/openstack-identity-api/src/docbkx/common/xsd

But Glance, Cinder, Swift and Quantum  don’t seem to have these. And even if we define these, they are not used today for code generation, just for documentation I believe. But we can certainly define XSDs for LBaaS and try hard to keep them up-to-date.


2)      Keystone integration

·         I think we should call out Keystone 2.0 as the version to be integrated with at this point.

·         We should mention the AuthZ rules for tenant access including the default using the token resolved tenantId and Quantum 2 style.

·         ‘The default authorization settings allow only administrative users to create resources on behalf of a different tenant.’ Not sure what you mean here?

I believe we are going rely on Quantum for KeyStone integration since the LBaaS APIs are going to be implemented as a Quantum API extension, so whatever KeyStone’s version Quantum supports, we will inherit the same. May be someone from the  Quantum team can clarify this further. If Quantum will integrate with KeyStone 2 in Grizzly, then I’ll call out this in the spec for LBaaS.


3)      Pagination

·         All GET’s which can return lengthy lists should support a pagination technique as the ‘limit and marker’ method use in other OS APIs.

Here again, not all OpenStack APIs support pagination. The following APIs do:


·         Compute: http://docs.openstack.org/api/openstack-compute/2/content/Paginated_Collections-d1e664.html

·         KeyStone: http://docs.openstack.org/api/openstack-identity-service/2.0/content/Paginated_Collections-d1e325.html

·         Swift: http://docs.openstack.org/api/openstack-object-storage/1.0/content/paging-objects.html


But Glance, Cinder and Quantum don’t seem to support pagination. We’ll discuss this in the next meeting as to whether to introduce this in LBaaS. I certainly would like  to see it.


4)      Bulk Operations

·         ‘Bulk operations are always performed atomically, meaning that either all or none of the objects in the request body are created.’

·         Does this imply that partial failures on the service are ‘unwound’ or rolled back? This seems complex.

This was written before I understood how Quantum implements Bulk operations. Given the complexity of doing rollback and reporting errors on bulk, we decided in the last meeting that we are going to postpone support for this (not in first release). Do you feel differently about this?


5)      API extensions

·         The assumption is that we will use the exact same API extension framework devised in Nova including how extensions are advertised and integrated.

·         Does this imply XSDs?

See previous answer on XSD use :-)


6)      Limits

·         How are things like /limits handled as you had in Atlas ( max LBs, max lengths, max members, etc )

Good point. I agree, it would be useful to have tenant resource limits returned by the service. For the sake of resource management, we would need a limit anyway.


7)      Data Model

·         From a modeling perspective I see that VIP has a ‘lb_method’.  I see this more as an attribute of the logical LB and not part of  the virtual IP.

·         Can this instead become only an attribute of the Pool?

Yes ☺ This is what was decided in the last meeting.


8)      204 on Deletes

·         Deletes commonly return 204 status within OS APIs.

Agreed. Will update the doc.


9)      /stats

·         I think that a /stats call should be allowed to return lazy stats where this is not real time. If so, we should mention it as perhaps delayed up to N minutes.

Yes you are right, we do need to clarify the service’s behavior wrt collecting stats.


10)    Dangling references

·         Since you have modeled VIPs, members and health monitors as their own collections, how do we handle cases where something is deleted but still referenced by a pool?

·         Do we prohibit the delete until all references are also deleted?

·         Do we put the pool in an invalid state?

The idea here, is that when you delete a resource, the LBaaS service knows what other resources are using it and will update the references. So for example, if you delete a member, the pool’s array of members is automatically updated. So, there should be no dangling references.


Thanks again Peter for your thorough reading and comments !

Youcef









From: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]<mailto:[mailto:Youcef.Laribi at eu.citrix.com]>
Sent: Friday, October 26, 2012 8:03 PM
To: Sachin Thakkar; Serge Maskalik; Eugene Nikanorov; Ilya Shakhat; Samuel Bercovici; Rudra Rugge; Alex Gosse; Leon Cui; Brent Busby; Kobi Samoray; Anand Palanisamy; John Gruber; Chinmay Naik; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov; Salvatore Orlando; Mellquist, Peter; Dan Wendlandt; OpenStack Development Mailing List (openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>)
Subject: [openstack-dev][Quantum][LBaaS] LBaaS API 1.0 spec draft

I have put a first draft of the LBaaS API on the wiki page  http://wiki.openstack.org/Quantum/LBaaS/API_1.0, so please have a look before next week’s meeting. There is still some work to be done on it, but the essential details to start the implementation should be there.

Thanks,
Youcef

From: Youcef Laribi
Sent: Friday, October 26, 2012 10:16 AM
To: 'Sachin Thakkar'
Cc: Eugene Nikanorov; Ilya Shakhat; Samuel Bercovici; Rudra Rugge; Alex Gosse; Leon Cui; Brent Busby; Kobi Samoray; Anand Palanisamy; John Gruber; Chinmay Naik; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov; Salvatore Orlando; Peter Mellquist; Dan Wendlandt; Serge Maskalik
Subject: RE: Specifying Tenant-ID in REST API URLs

Thanks Sachin for filing a blueprint for this!

From: Sachin Thakkar [mailto:sthakkar at vmware.com]
Sent: Friday, October 26, 2012 10:06 AM
To: Youcef Laribi
Cc: Eugene Nikanorov; Ilya Shakhat; Samuel Bercovici; Rudra Rugge; Alex Gosse; Leon Cui; Brent Busby; Kobi Samoray; Anand Palanisamy; John Gruber; Chinmay Naik; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov; Salvatore Orlando; Peter Mellquist; Dan Wendlandt; Serge Maskalik
Subject: Re: Specifying Tenant-ID in REST API URLs

Excellent, thanks Youcef. I've filed this blueprint for tracking purposes - https://blueprints.launchpad.net/quantum/+spec/lbaas-restapi-tenant

When we're ready we can formalize the wiki link, object model etc and fill in the specification section. For now, I've simply pointed to the etherpad from the summit.

All, please feel free to join the bp.

Thanks,
Sachin
________________________________
From: "Youcef Laribi" <Youcef.Laribi at eu.citrix.com<mailto:Youcef.Laribi at eu.citrix.com>>
To: "Serge Maskalik" <smaskalik at vmware.com<mailto:smaskalik at vmware.com>>
Cc: "Eugene Nikanorov" <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>>, "Ilya Shakhat" <ishakhat at mirantis.com<mailto:ishakhat at mirantis.com>>, "Samuel Bercovici" <SamuelB at radware.com<mailto:SamuelB at radware.com>>, "Rudra Rugge" <rrugge at vmware.com<mailto:rrugge at vmware.com>>, "Alex Gosse" <Alex.Gosse at riverbed.com<mailto:Alex.Gosse at riverbed.com>>, "Leon Cui" <lcui at vmware.com<mailto:lcui at vmware.com>>, "Brent Busby" <bbusby at ebay.com<mailto:bbusby at ebay.com>>, "Kobi Samoray" <KobiS at radware.com<mailto:KobiS at radware.com>>, "Anand Palanisamy" <apalanisamy at paypal.com<mailto:apalanisamy at paypal.com>>, "John Gruber" <J.Gruber at f5.com<mailto:J.Gruber at f5.com>>, "Chinmay Naik" <cnaik at paypal.com<mailto:cnaik at paypal.com>>, "Oleg Bondarev" <obondarev at mirantis.com<mailto:obondarev at mirantis.com>>, "Eugene Kirpichev" <ekirpichev at mirantis.com<mailto:ekirpichev at mirantis.com>>, "Roman Alekseenkov" <ralekseenkov at mirantis.com<mailto:ralekseenkov at mirantis.com>>, "Salvatore Orlando" <sorlando at nicira.com<mailto:sorlando at nicira.com>>, "Peter Mellquist" <peter.mellquist at hp.com<mailto:peter.mellquist at hp.com>>, "Sachin Thakkar" <sthakkar at vmware.com<mailto:sthakkar at vmware.com>>, "Dan Wendlandt" <dan at nicira.com<mailto:dan at nicira.com>>
Sent: Friday, October 26, 2012 9:55:13 AM
Subject: RE: Specifying Tenant-ID in REST API URLs
Serge,

I’m in the process of putting together the API spec by merging your API doc with mine, and following Quantum API style and naming conventions. Should be able to share something by the end of today.

Youcef

From: Serge Maskalik [mailto:smaskalik at vmware.com]
Sent: Thursday, October 25, 2012 10:15 PM
To: Youcef Laribi; Dan Wendlandt; Eugene Nikanorov; Ilya Shakhat; Samuel Bercovici; Rudra Rugge; Alex Gosse; Leon Cui; Brent Busby; Kobi Samoray; Anand Palanisamy; John Gruber; Chinmay Naik; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov; Salvatore Orlando; Peter Mellquist; Sachin Thakkar
Subject: Re: Specifying Tenant-ID in REST API URLs

Folks,

I just wanted to get a sense on activity for next week's sync-up. Do we have the Blueprints started? If so, can folks respond with active Blueprint URLs.

Youcef - how are the API definition going? Can you point to the latest, if possible? Thanks in advance.

  -Serge
________________________________
From: "Youcef Laribi" <Youcef.Laribi at eu.citrix.com<mailto:Youcef.Laribi at eu.citrix.com>>
To: "Salvatore Orlando" <sorlando at nicira.com<mailto:sorlando at nicira.com>>, "Peter Mellquist" <peter.mellquist at hp.com<mailto:peter.mellquist at hp.com>>
Cc: "Dan Wendlandt" <dan at nicira.com<mailto:dan at nicira.com>>, "Eugene Nikanorov" <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>>, "Ilya Shakhat" <ishakhat at mirantis.com<mailto:ishakhat at mirantis.com>>, "Leon Cui" <lcui at vmware.com<mailto:lcui at vmware.com>>, "Brent Busby" <bbusby at ebay.com<mailto:bbusby at ebay.com>>, "Kobi Samoray" <KobiS at radware.com<mailto:KobiS at radware.com>>, "Anand Palanisamy" <apalanisamy at paypal.com<mailto:apalanisamy at paypal.com>>, "John Gruber" <J.Gruber at f5.com<mailto:J.Gruber at f5.com>>, "Samuel Bercovici" <SamuelB at radware.com<mailto:SamuelB at radware.com>>, "Rudra Rugge" <rrugge at vmware.com<mailto:rrugge at vmware.com>>, "Alex Gosse" <Alex.Gosse at riverbed.com<mailto:Alex.Gosse at riverbed.com>>, "Serge Maskalik" <smaskalik at vmware.com<mailto:smaskalik at vmware.com>>, "Chinmay Naik" <cnaik at paypal.com<mailto:cnaik at paypal.com>>, "Oleg Bondarev" <obondarev at mirantis.com<mailto:obondarev at mirantis.com>>, "Eugene Kirpichev" <ekirpichev at mirantis.com<mailto:ekirpichev at mirantis.com>>, "Roman Alekseenkov" <ralekseenkov at mirantis.com<mailto:ralekseenkov at mirantis.com>>
Sent: Thursday, October 25, 2012 4:45:46 PM
Subject: RE: Specifying Tenant-ID in REST API URLs
Thanks Salvatore.

So Peter, an admin role should be able to access any tenant’s  resources by simply using the query string filtering mechanism of the API:

GET /v2.0/vips?tenant_id=100   (with keystone auth middleware returning tenant_id=456, role=admin)

This should return the vips of tenant_id 100 even though the caller is actually tenant 456 (who has an admin role). If tenant 456 wasn’t an admin, I suspect he would get an “empty” result, rather than the usual “401 Unauthorized” error (that would be the only slight downside to this).

Are we then comfortable with removing the tenant_id from the URLs?

Youcef


From: Salvatore Orlando [mailto:sorlando at nicira.com]
Sent: Thursday, October 25, 2012 4:22 PM
To: Youcef Laribi
Cc: Dan Wendlandt; Mellquist, Peter; Eugene Nikanorov; Ilya Shakhat; Leon Cui; Busby, Brent; Kobi Samoray; Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra Rugge; Alex Gosse; Serge Maskalik; Naik, Chinmay; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov
Subject: Re: Specifying Tenant-ID in REST API URLs

Yes it is correct.
The default behaviour is that each tenant will get its own object only, unless it is an administrator, in which case it will get all objects.
This behaviour is actually not enforced by the policy engine, but hardcoded in the db management logic.

The policy engine however regulates details such as "shared" and "external" networks. What you find in policy.json is a default set of policies that you can customize according to your needs; for instance you can specify more roles.
Policy.json also controls who can perform some operations; as an example the creation of "shared" and "external" networks is reserved to admins only by default, but you can allow any tenant, or a specific group of tenants, to perform this operations, just by editing the file (you won't even need to restart Quantum).

Salvatore

On 26 October 2012 00:16, Youcef Laribi <Youcef.Laribi at eu.citrix.com<mailto:Youcef.Laribi at eu.citrix.com>> wrote:
So if I understood the code correctly, in Quantum, there are 2 basic roles:

  1. Admin
  2. Normal

If the user making the request has an "admin" role (according to the keystone token in the request header), then when he issues a Quantum API request like:

        GET /v2.0/networks

He will get all the networks of all the tenants.

If however, the user doesn't have an "admin" role (normal user), then he will get only his own networks for the same call (the result is filtered).

Is my understanding correct?

Youcef


-----Original Message-----
From: Dan Wendlandt [mailto:dan at nicira.com<mailto:dan at nicira.com>]
Sent: Thursday, October 25, 2012 3:38 PM
To: Youcef Laribi
Cc: Mellquist, Peter; Eugene Nikanorov; Ilya Shakhat; Leon Cui; Busby, Brent; Kobi Samoray; Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra Rugge; Alex Gosse; Serge Maskalik; Naik, Chinmay; Salvatore Orlando; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov
Subject: Re: Specifying Tenant-ID in REST API URLs

On Thu, Oct 25, 2012 at 3:25 PM, Youcef Laribi <Youcef.Laribi at eu.citrix.com<mailto:Youcef.Laribi at eu.citrix.com>> wrote:
> Yes, they would be. For the sake of consistency I prefer the LBaaS
> APIs to use a same style and conventions as the Quantum APIs if
> possible. So, I’m waiting to hear clarifications from Dan or Salvatore
> on how authorization is handled in Quantum without the tenant-id being in the URL.

Here's the standard auth.py code that grabs keystone info from the headers and puts it in the context object:

https://github.com/openstack/quantum/blob/master/quantum/auth.py

This is then returned whenever the context of a request is asked for:

https://github.com/openstack/quantum/blob/master/quantum/api/v2/resource.py#L43

This context object is then used in validation methods in https://github.com/openstack/quantum/blob/master/quantum/api/v2/base.py
as well as passed to all plugin methods:

https://github.com/openstack/quantum/blob/master/quantum/quantum_plugin_base_v2.py

Dan


>
>
>
> Youcef
>
>
>
> From: Mellquist, Peter [mailto:peter.mellquist at hp.com<mailto:peter.mellquist at hp.com>]
> Sent: Thursday, October 25, 2012 3:17 PM
>
>
> To: Youcef Laribi; Eugene Nikanorov
> Cc: Ilya Shakhat; Leon Cui; Busby, Brent; Kobi Samoray; Dan Wendlandt;
> Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra Rugge; Alex
> Gosse; Serge Maskalik; Naik, Chinmay; Salvatore Orlando; Oleg
> Bondarev; Eugene Kirpichev; Roman Alekseenkov
> Subject: RE: Specifying Tenant-ID in REST API URLs
>
>
>
> Yes this is the question.
>
>
>
> I am assuming our data model will have resources contained by tenants
> like you did within Atlas and is common across Openstack.
>
>
>
> Peter.
>
>
>
> From: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com<mailto:Youcef.Laribi at eu.citrix.com>]
> Sent: Thursday, October 25, 2012 2:47 PM
> To: Mellquist, Peter; Eugene Nikanorov
> Cc: Ilya Shakhat; Leon Cui; Busby, Brent; Kobi Samoray; Dan Wendlandt;
> Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra Rugge; Alex
> Gosse; Serge Maskalik; Naik, Chinmay; Salvatore Orlando; Oleg
> Bondarev; Eugene Kirpichev; Roman Alekseenkov
> Subject: RE: Specifying Tenant-ID in REST API URLs
>
>
>
> Peter,
>
>
>
> Agree. Hence my earlier question to the Quantum people of how they
> handle Authorization with the absence of “tenant-id” from the URL for
> your exact scenario (e.g. admin role finding out the networks of tenant A).
>
>
>
> Youcef
>
>
>
> From: Mellquist, Peter [mailto:peter.mellquist at hp.com<mailto:peter.mellquist at hp.com>]
> Sent: Thursday, October 25, 2012 2:41 PM
> To: Youcef Laribi; Eugene Nikanorov
> Cc: Ilya Shakhat; Leon Cui; Busby, Brent; Kobi Samoray; Dan Wendlandt;
> Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra Rugge; Alex
> Gosse; Serge Maskalik; Naik, Chinmay; Salvatore Orlando; Oleg
> Bondarev; Eugene Kirpichev; Roman Alekseenkov
> Subject: RE: Specifying Tenant-ID in REST API URLs
>
>
>
> Hi,
>
>
>
> My point was only to ensure we allow a way to achieve cross tenant
> access for an admin role.  Normally, the Keystone tenantId must  match
> the tenantId in the resource being accessed but for admin roles the
> keystone tenantId has scope to access all tenants. For example in the
> Atlas style, for logical load balancers which are owned by the tenant
> they are not shared unless you have special authorization, like an administrator.
>
>
>
> Examples:
>
> GET /v2/100/loadbalancers   ( with keystone auth middleware returning
> tenantId=100 )
>
> This would be authorized , 100 can access 100’s resources
>
>
>
> GET /v2/101/loadbalancers   ( with keystone auth middleware returning
> tenantId=100 )
>
> Not authorized, 100 cannot access 101’s resources
>
>
>
> GET /v2/100/loadbalancers   ( with keystone auth middleware returning
> tenantId=200 , role = admin)
>
> Authorized, 200 is admin
>
>
>
> If you drop the tenantId in the URI you have..
>
> GET /V2/loadbalancers    ( with keystone auth middleware returning
> tenantId=100 , so you can only access 100’s resources)
>
> If I am the admin and I need to access a tenants LBs how is this done?
>
>
>
> Here is a good paper on the topic :
>
> https://github.com/RackerWilliams/multi-tenant-accounting/blob/master/
> tenants.pdf?raw=true
>
>
>
>
>
> Peter.
>
>
>
>
>
> From: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com<mailto:Youcef.Laribi at eu.citrix.com>]
> Sent: Thursday, October 25, 2012 11:42 AM
> To: Eugene Nikanorov; Mellquist, Peter
> Cc: Ilya Shakhat; Leon Cui; Busby, Brent; Kobi Samoray; Dan Wendlandt;
> Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra Rugge; Alex
> Gosse; Serge Maskalik; Naik, Chinmay; Salvatore Orlando; Oleg
> Bondarev; Eugene Kirpichev; Roman Alekseenkov
> Subject: RE: Specifying Tenant-ID in REST API URLs
>
>
>
> Peter, Eugene,
>
>
>
> Changing to the subject to a more appropriate title.
>
>
>
> Just for information, Quantum changed its API style between 1.0
> version (which had tenant-id in the URL, like the rest of OpenStack
> APIs) and the
> 2.0 version (which doesn’t):
>
>
>
> Quantum API 1.0:
> http://docs.openstack.org/api/openstack-network/1.0/content/index.html
>
> Quantum API 2.0:
> http://docs.openstack.org/api/openstack-network/2.0/content/index.html
>
>
>
> Can somebody from the Quantum team (Dan or Salvatore) explain the
> reasoning behind the change and how is Authorization handled in 2.0 vs. 1.0?
>
>
>
> Thanks
>
> Youcef
>
>
>
> From: Eugene Nikanorov [mailto:enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>]
> Sent: Thursday, October 25, 2012 10:52 AM
> To: Mellquist, Peter
> Cc: Ilya Shakhat; Leon Cui; Youcef Laribi; Busby, Brent; Kobi Samoray;
> Dan Wendlandt; Palanisamy, Anand; John Gruber; Samuel Bercovici; Rudra
> Rugge; Alex Gosse; Serge Maskalik; Naik, Chinmay; Salvatore Orlando;
> Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov
> Subject: Re: 答复: Questions to REST API proposal
>
>
>
> Hi Peter,
>
>
>
>> With Keystone middleware the requestors tenantId is injected in the
>> headers of the request, so the API server can see the tenant of the
>> client making the request.
>
> That's correct. That will be used to make authorization decision
> (whether tenant can access the resource)
>
>
>
>> For example, If I am the admin of the LB then my tenant may have
>> access to all LBs.
>
> I think we want it in a bit different way: LBs as a devices may be
> shared
> (hardware) or private (VMs).
>
> LB (VIP, In our new API terminology) deployed on hardware device
> should be accessed only from the tenant that have deployed it. VIP
> deployed on the shared device are visible to provider, but tenant sees
> only those VIPs that it has deployed.
>
> If tenant creates it's own private device (by launching VM with, say,
> HAProxy), other tenants can't deploy VIPs on that device and can't see
> neither device itself nor VIP deployed on it.
>
>
>
> Are there reasons to make lbaas API in different style from the Core
> Quantum API v2.0?
>
>
>
> Thanks,
>
> Eugene.
>
> On Thu, Oct 25, 2012 at 8:45 PM, Mellquist, Peter
> <peter.mellquist at hp.com<mailto:peter.mellquist at hp.com>>
> wrote:
>
> Hi Eugene,
>
>
>
> With Keystone middleware the requestors tenantId is injected in the
> headers of the request, so the API server can see the tenant of the
> client making the request. The middleware resolves a token or signed
> request to this tenant. Getting rid of the tenantId from the URI will
> not allow cross tenant access. For example, If I am the admin of the
> LB then my tenant may have access to all LBs.  Also, most all of the
> other OS APIs have tenant in the URI as resources are organized by tenant.
>
>
>
> Peter.
>
>
>
> From: Eugene Nikanorov [mailto:enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>]
> Sent: Thursday, October 25, 2012 3:38 AM
> To: Ilya Shakhat
> Cc: Leon Cui; Youcef Laribi; Busby, Brent; Kobi Samoray; Dan
> Wendlandt; Palanisamy, Anand; John Gruber; Mellquist, Peter; Samuel
> Bercovici; Rudra Rugge; Alex Gosse; Serge Maskalik; Naik, Chinmay;
> Salvatore Orlando; Oleg Bondarev; Eugene Kirpichev; Roman Alekseenkov
> Subject: Re: 答复: Questions to REST API proposal
>
>
>
> Folks,
>
>
>
> I suggest we stick with v2.0 style of calls, where there is no /tenants/XYZ.
>
> Our current vision is that API calls should look like following:
>
>
>
> /v2.0/balancer/lbaas/vips.json?param1=value1&param2=value2
>
> /v2.0/balancer/lbaas/vips/{vip_id}.json?param1=value1&param2=value2
>
>
>
> where:
>
>  - balancer - type of advanced service within quantum
>
>  - lbaas - particular implementation of service "balancer"
>
>  - flat resource API, like in quantum API v2.0
>
>
>
> Additional parameters like tenant_id, lb id, etc, are provided in
> parameters.
>
> If we're talking about id of resource being accessed, that it is
> provided in url, just like in current quantum API, e.g.
>
>
>
> .../vips/{vip_id}.json?...  - for operations on particular vip.
>
>
>
> Thanks,
>
> Eugene.
>
> On Thu, Oct 25, 2012 at 2:20 PM, Ilya Shakhat <ishakhat at mirantis.com<mailto:ishakhat at mirantis.com>> wrote:
>
> One point for flat URL structure is simplicity of search operations.
> The use
> case:
>
>  * tenant have a large number of back-end servers deployed on several
> load-balancers;
>
>  * there is a monitoring system that reports only host-name of
> back-end;
>
>  * users needs to put back-end server out of service.
>
> In case of flat addressing, user can find backend id by query like
> this: GET /lbaas/v1.0/tenants/1000/members?name=backendname
>
> But if addressing is hierarchical, then he needs to iterate all pools.
>
>
>
> Thanks,
>
> Ilya
>
>
>
> 2012/10/25 Leon Cui <lcui at vmware.com<mailto:lcui at vmware.com>>
>
> Hi Youcef,
>
> Both ways looks not good enough in my perspective.  The
> Atlas/Equilibrium style is too deep in hierarchy while the Quantum
> style is a bit too flat. I think we may consider the following principles in API design:
>
> 1.       “part-of” relationship between objects.  If object B is “part of”
> object A, then the url hierarchy may look like /A/B.
>
> 2.       Object reuse. Can an object reused by multiple objects?  If object
> B can be referred by both A1 and A2, then B probably should be in the
> same url level as A.  For instance, in our design, do we prevent a
> pool shared by multiple VIPs? If not, Pool should be in the same url
> level as VIP. It’s the same for HealthMonitor object. A HealthMonitor
> object should be able to bind to multiple pools (implicitly there will
> be multiple healthMonitor instances created and bound to each pool member).
>
>
>
> Not sure if we have the same understanding against the healthMonitor
> concept. A healthMonitor object defines a type of monitor (e.g.
> TCP/HTTP/HTTPS) with generic settings (e.g. interval, timeout).  When
> a healthMonitor is bound to a pool, the LBaaS system will implicitly
> create a healthMonitorInstance object for each pool member, and by
> default use the ipAddress/port of the pool member. I believe this is
> how F5 Big-IP monitor is defined and we may follow this practice.
>
>
>
> So my suggest would be, assuming all vips/pools/healthmonitors should
> be only in a single tenant scope, then the following URLs should be used:
>
> /lbaas/v1.0/tenants
>
> /lbaas/v1.0/tenants/1000/vips
>
> /lbaas/v1.0/tenants/1000/pools
>
> /lbaas/v1.0/tenants/1000/healthmonitors
>
> /lbaas/v1.0/tenants/1000/pools/1/members
>
>
>
> Please let me know your thoughts.
>
>
>
> Thanks
>
> Leon
>
> 发件人: Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com<mailto:Youcef.Laribi at eu.citrix.com>]
> 发送时间: 2012年10月25日 9:02
> 收件人: Leon Cui; 'Busby, Brent'; 'Ilya Shakhat'
> 抄送: 'Kobi Samoray'; 'Dan Wendlandt'; 'Palanisamy, Anand'; 'John
> Gruber'; 'Peter Mellquist'; 'Samuel Bercovici'; 'Rudra Rugge'; 'Alex
> Gosse'; 'Serge Maskalik'; 'Naik, Chinmay'; 'Salvatore Orlando';
> 'Eugene Nikanorov'; 'Oleg Bondarev'; 'Eugene Kirpichev'; 'Roman Alekseenkov'
> 主题: RE: Questions to REST API proposal
>
>
>
> Both are valid ways of expressing the resource model but the payloads
> for the objects would be different in each case.
>
>
>
> If we take the Atlas/Equilibrium style, where the context is implied
> from the URL:
>
>
>
> http://lbaas-service/lbaas/v1.0/tenants/1000/vips/4/pools/1/members
>
>
>
> Here,  we know we are talking about the members of pool 1 which
> belongs to vip 4 of tenant 1000. There is an implied hierarchy by just
> looking at the URL. When we create a member, the payload doesn’t need
> to specify the vip, the pool and the tenant, since these are already
> specified in the URL (and you can only create members through these
> form of URLs). So, a member payload here could be:
>
>
>
> {
>
>   "member": {
>
>            "address": "192.168.130.51",
>
>            "port" : 80,
>
>            "connectionlimit": 500,
>
>            "weight" : 2
>
>            "adminState" : "ENABLED"
>
>   }
>
> }
>
>
>
> Also, the IDs of members can be relative to pools, they don’t need to
> be unique across pools and across vips and tenants (although you can
> create unique ones in any case).
>
>
>
> If we take however the Quantum style, where objects are defined at the
> top-level, then we need to create a member like this:
>
>
>
> POST http://lbaas-service/lbaas/v1.0/members
>
>
>
> {
>
>   "member": {
>
>             "tenant-id" : "1000",
>
>            "vip-id" : "4",
>
>            "pool-id" : "1",
>
>             "address": "192.168.130.51",
>
>            "port" : 80,
>
>            "connectionlimit": 500,
>
>            "weight" : 2
>
>            "adminState" : "ENABLED"
>
>   }
>
> }
>
>
>
>
>
> Here we needed to specify all the information that was implied before
> from the URL, and these attributes are required each time we need to
> create a member.
>
>
>
> The advantage of the Quantum-style approach, is you can list all
> members regardless of which vips, pools or tenants they belong to, by
> simply doing the following:
>
>
>
> GET  http://lbaas-service/lbaas/v1.0/members
>
>
>
> This is especially useful for admin roles, where you want to list all
> vips or all pools regardless of their containing object. This is hard
> to do in Atlas/Equilibrium style (unless you have a convention that
> can substitute an ID in the URL with a  wildcard).
>
>
>
> If however, you want to find out the members of pool 4 in vip 1 in
> Quantum style,  then you have to use a query string style of filtering:
>
>
>
> GET http://lbaas-service/lbaas/v1.0/members?vip-id=1&pool-id=4
>
>
>
> In Atlas/Equilibrium, this would simply be:
>
>
>
> GET
> http://lbaas-service/lbaas/v1.0/tenants/1000/vips/4/pools/1/members
>
>
>
> So, both approaches are valid (although with the Quantum style, you
> can do arbitrary filtering on attributes).
>
>
>
> I think we should adopt the same API style between Quantum and LBaaS,
> otherwise it will be confusing for people using the API.
>
>
>
> Youcef
>
>
>
> From: Leon Cui [mailto:lcui at vmware.com<mailto:lcui at vmware.com>]
> Sent: Wednesday, October 24, 2012 4:42 PM
> To: 'Busby, Brent'; 'Ilya Shakhat'; Youcef Laribi
> Cc: 'Kobi Samoray'; 'Dan Wendlandt'; 'Palanisamy, Anand'; 'John
> Gruber'; 'Peter Mellquist'; 'Samuel Bercovici'; 'Rudra Rugge'; 'Alex
> Gosse'; 'Serge Maskalik'; 'Naik, Chinmay'; 'Salvatore Orlando';
> 'Eugene Nikanorov'; 'Oleg Bondarev'; 'Eugene Kirpichev'; 'Roman Alekseenkov'
> Subject: 答复: Questions to REST API proposal
>
>
>
> I agree with Busby that sometimes we need this “as-part-of” relationship.
> Pool:member is a good example.
>
>
>
> The top class objects should be defined independently and between
> them, the relationship is much like “association” which is defined by
> referring to the objectId.  In current LBaaS model, those top objects
> would be VIP, Pool, HealthMonitor. We should define CRUD APIs for each top objects by root path:
>
> /loadbalancer/vips
>
> /loadbalancer/pools
>
> /loadbalancer/healthmonitors
>
>
>
> In my perspective, member is not a top class object because it’s only
> meaningful only if it belong to a pool.  The path for members should be:
>
> /loadbalancer/pools/members
>
>
>
> Thanks
>
> Leon
>
> 发件人: Busby, Brent [mailto:bbusby at ebay.com<mailto:bbusby at ebay.com>]
> 发送时间: 2012年10月25日 0:25
> 收件人: Ilya Shakhat; Youcef Laribi
> 抄送: Kobi Samoray; Dan Wendlandt; Palanisamy, Anand; John Gruber; Peter
> Mellquist; Samuel Bercovici; Rudra Rugge; Alex Gosse; Leon Cui; Serge
> Maskalik; Naik, Chinmay; Salvatore Orlando; Eugene Nikanorov; Oleg
> Bondarev; Eugene Kirpichev; Roman Alekseenkov
> 主题: Re: Questions to REST API proposal
>
>
>
> For #1 – Sometimes the relationship between pool and member defines
> the member.
>
> For example: on a netscaler health monitors are bound at the service
> level, which is the member in this API.  If the user defines the
> health monitors at the pool level, then we need to know what members
> are part of the pool to bind the health monitor to all pool members.
> Additional health monitors can be bound to the member individually,
> but it's membership in the pool means that it must also have the
> pool's health monitors bound. Should we show monitors bound to the pool when listing just the member independently?
> Should we allow the user to remove the health monitors bound to the
> member via pool membership?
>
>
>
> There are probably other examples where member inherits some trait
> from the pool, but this is just the first example that popped in me head.
>
>
>
> ________________________________
>
> M. Brent Busby
>
> eBay, Inc.
>
> 602-316-8599<tel:602-316-8599>
>
>
>
> From: Ilya Shakhat <ishakhat at mirantis.com<mailto:ishakhat at mirantis.com>>
> Date: Wednesday, October 24, 2012 4:17 AM
> To: Youcef Laribi <Youcef.Laribi at eu.citrix.com<mailto:Youcef.Laribi at eu.citrix.com>>
> Cc: Kobi Samoray <KobiS at radware.com<mailto:KobiS at radware.com>>, "M. Brent Busby"
> <bbusby at ebay.com<mailto:bbusby at ebay.com>>, Dan Wendlandt <dan at nicira.com<mailto:dan at nicira.com>>, "Palanisamy, Anand"
> <apalanisamy at paypal.com<mailto:apalanisamy at paypal.com>>, John Gruber <J.Gruber at F5.com<mailto:J.Gruber at F5.com>>, Peter
> Mellquist <peter.mellquist at hp.com<mailto:peter.mellquist at hp.com>>, Samuel Bercovici
> <SamuelB at Radware.com<mailto:SamuelB at Radware.com>>, Rudra Rugge <rrugge at vmware.com<mailto:rrugge at vmware.com>>, Alex Gosse
> <Alex.Gosse at riverbed.com<mailto:Alex.Gosse at riverbed.com>>, Leon Cui <lcui at vmware.com<mailto:lcui at vmware.com>>, Serge Maskalik <smaskalik at vmware.com<mailto:smaskalik at vmware.com>>, "Naik, Chinmay"
> <cnaik at paypal.com<mailto:cnaik at paypal.com>>, Salvatore Orlando <sorlando at nicira.com<mailto:sorlando at nicira.com>>, Eugene
> Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>>, Oleg Bondarev
> <obondarev at mirantis.com<mailto:obondarev at mirantis.com>>, Eugene Kirpichev <ekirpichev at mirantis.com<mailto:ekirpichev at mirantis.com>>,
> Roman Alekseenkov <ralekseenkov at mirantis.com<mailto:ralekseenkov at mirantis.com>>
> Subject: Questions to REST API proposal
>
>
>
> Hi Youcef,
>
>
>
> We have some questions on REST API discussion.
>
>
>
> 1) In Quantum API all objects "live" independently, even if they
> depend on each other (like subnet and network). List of subnets can be
> queried by request '/v2.0/subnets' and network_id is optional
> parameter to request. In LBaaS we had a different style, and dependent
> objects were accessible by sub-path (loadbalancers/loadbalancer-id/nodes).
>
> From our perspective "plain" style is more preferable, since it would
> be easier for client to access object by its id only and parent id is
> superfluous. If needed the parent id may be set as filter (HTTP parameter).
> For example, we propose to change:
> '/vips/{vipId}/pools/{poolId}/members/{memberId}' -> '/members/{memberId}'.
>
>
>
> 2) In VIP we have attribute 'networkId'. It allows LBaaS to create IP
> address in the specified network, so the user doesn't need to do it
> separately. I see how this will work for HW LB, but how will this work
> for virtual? If virtual LB is created by user, then user may decide to
> keep it accessible internal (=leave IP provided by Nova), or make it
> external (=associate FIP). So in that case LBaaS needs to deal with
> Quantum Port rather than with Quantum Network object. What do you think about this?
>
>
>
> 3) For some items we need a way to provide extra parameters, for
> example 'sessionPersistence' may have parameter 'http_header_name'.
> How will we store them? As json-object under 'extra' attribute?
>
>
>
> Thanks,
>
> Ilya
>
>
>
>
>
>



--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com<http://www.nicira.com>
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121101/f4bf63cf/attachment-0001.html>