[openstack-dev] [quantum] [LBaaS] Health monitors REST resource
Salvatore Orlando
sorlando at nicira.com
Fri Nov 16 17:32:24 UTC 2012
Hi Youcef,
Thanks for the clarification. I was pretty sure this was well thought in
the API design, as I wrote in my previous post :)
The naming for the attribute on the pool which references health_monitors
is a discussion worth having. I have very little data points for comparison
with other parts of Quantum and Openstack APIs. The only similar bit is
probably the network-subnet relationship. In the response for a GET
/networks/<network-id> a list of subnet identifiers is returned. The name
for the list attribute is just 'subnets'. However, as this is a read-only
attribute there is no need for handling it as a sub-resource. Response
sample is available at [1]
Between handling the collection of health monitor references as a
sub-resource and having member actions for CRUD operations, I prefer the
first solution. I am happy to offer any kind of supports for the relevant
changes in the apiv2 modules. The other option is to regard health_monitors
as a 'list' attribute. Which means that a POST/PUT will create/update the
whole list. This is practical from server-side perspective, but has also
drawbacks. Indeed it adds burden to the client; for instance, in order to
add an element to the list you'll need a GET and then a PUT; and it also
causes confusion because of the fact that our PUT actually implement patch
semantics.
Salvatore
[1]
http://docs.openstack.org/api/openstack-network/2.0/content/List_Networks_Detail.html#d6e858
On 16 November 2012 18:04, Youcef Laribi <Youcef.Laribi at eu.citrix.com>wrote:
> Changing the subject line…****
>
> ** **
>
> Health monitors “/health_monitors/” are a top resource in the API and are
> retrieved/added/removed/updated through their CRUD operations on this top
> resource.****
>
> ** **
>
> The subresource “/pools/{pool_id}/health_monitors“ is used for
> associating already existing health monitors (created above) with an
> existing pool, or for retrieving the health monitors associated with a
> pool. It is a collection (list) that only contain IDs of health monitors
> not the health monitors themselves. We can call this resource “
> /pools/{pool_id}/health_monitor_references“ or “
> /pools/{pool_id}/pool_health_monitors” if we like, but I felt this was
> ugly and I think there is no issue or ambiguity in the definition of API
> itself as all operations are clearly described. But if you think changing
> its name helps, I can do that J Would like to hear what others in the
> team think.****
>
> ** **
>
> Youcef****
>
> ** **
>
> *From:* Oleg Bondarev [mailto:obondarev at mirantis.com]
> *Sent:* Friday, November 16, 2012 1:12 AM
> *To:* Youcef Laribi; 'OpenStack Development Mailing List'
> *Subject:* RE: [openstack-dev] [quantum] Quantum extension framework issue
> ****
>
> ** **
>
> Hi guys,****
>
> ** **
>
> I just want to clarify some things regarding health monitors in LBaaS API:
> actually it is not completely a sub-resource of pool objects. ****
>
> According to the API it is a separate resource which can be
> added/showed/updated/deleted (with GET/POST.. “/v1.0/health_monitors/..”
> rest calls) in order to be reusable in different pools and probably
> anywhere else as Sasha mentioned. Youcef please correct me if I am wrong
> here.****
>
> Speaking about sub-resources I think following rest call: ****
>
> ** **
>
> POST /v1.0/pools/{pool_id}/health_monitors****
>
> ** **
>
> is intended to *create* a sub-resource of health monitor for the pool and
> not to *add* an existing health monitor to the pool.****
>
> Also I think having health monitors as a separate resource and as a
> sub-resource of a pool at the same time is not correct.****
>
> So my vision is to leave health monitors as a separate resource and to use
> member actions for the purpose of getting/associating/disassociating health
> monitors with a pool:****
>
> Get health monitors of a pool:****
>
> GET /v1.0/pools/{pool_id}/get_health_monitors****
>
> Associate health monitors with a pool:****
>
> PUT /v1.0/pools/{pool_id}/add_health_monitors****
>
> {****
>
> "health_monitors" : [****
>
> "f3eeab00-8367-4524-b662-55e64d4cacb5"****
>
> ]****
>
> }****
>
> Disassociate health monitors from a pool:****
>
> PUT /v1.0/pools/{pool_id}/delete_health_monitors****
>
> {****
>
> "health_monitors" : [****
>
> "f3eeab00-8367-4524-b662-55e64d4cacb5"****
>
> ]****
>
> }****
>
> ** **
>
> Please share your thoughts.****
>
> ** **
>
> Thanks,****
>
> Oleg****
>
> ** **
>
> *From:* Sasha Ratkovic [mailto:sasharatkovic at juniper.net<sasharatkovic at juniper.net>]
>
> *Sent:* Friday, November 16, 2012 3:38 AM
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [quantum] Quantum extension framework issue
> ****
>
> ** **
>
> One comment: even though health_monitor is introduced as part of LB
> effort, it has more general applicability. So having it under LB specific
> resource may pose usability problems down the road when new services are
> introduced, if health monitor is to be re-used for that purpose. One
> solution is to make it "first class" citizen with relationship to "pool"
> and/or make "pool" assume more abstract pooling semantics, reusable as well
> across multiple services in the future. (yes, I am talking about "groups"
> here :) ).****
>
> ** **
>
> *From: *Salvatore Orlando <sorlando at nicira.com>
> *Reply-To: *OpenStack Development Mailing List <
> openstack-dev at lists.openstack.org>
> *Date: *Thursday, November 15, 2012 7:40 AM
> *To: *OpenStack Development Mailing List <
> openstack-dev at lists.openstack.org>
> *Subject: *Re: [openstack-dev] [quantum] Quantum extension framework issue
> ****
>
> ** **
>
> Hi Oleg, ****
>
> ** **
>
> This is exactly what I was talking about.****
>
> One thing you might want to consider before choosing for one direction or
> the other is that at the moment Quantum API does not use sub resources at
> all.****
>
> There was a long discussion on this regard while designing the v2 API. The
> gist of the discussion was that if a resource needed sub-resources then
> there was a case for a sub-resource to become a 'first citizen' in the API.
> I am pretty sure you already have mulled over whether health_monitors
> should be a resource of their own, a sub resource of the pool, or a
> multi-valued attribute of the pool, but I wanted to give you a heads-up
> anyway.****
>
> ** **
>
> On your technical questions I have some answers inline.****
>
> ** **
>
> Salvatore****
>
> On 15 November 2012 15:40, Oleg Bondarev <obondarev at mirantis.com> wrote:**
> **
>
> Hi folks,****
>
> ****
>
> As Salvatore said there is a way to specify parent for a resource (see
> quantum.extensions.extensions.ResourceExtension) which allows route mapping
> for rest calls like:****
>
> ****
>
> POST /v1.0/pools/{pool_id}/health_monitors****
>
> DELETE /v1.0/pools/{pool_id}/health_monitors/{id}****
>
> …****
>
> ****
>
> In this case corresponding resource controller should be aware of resource
> parent and be able to handle CRUD operations with an additional parent_id
> parameter. Currently it doesn’t. Actually I am speaking about
> quantum.api.v2.base.Controller – so, Salvatore, do you think it is the
> right place to include sub-resource/parent handling?****
>
> ** **
>
> Working on controllers in quantum.api.v2 is the best option in my opinion.
> ****
>
> This however depends on how the route mapper associates controllers with
> sub resources. Currently, the extension framework and the core API use two
> distinct code paths: the former uses
> quantum.extensions.extensions.ExtensionMiddleware whereas the latter uses
> quantum.api.v2.router.APIRouter (this is for historical reasons only; as
> far as I can recall, there's no technical reason for this). The Extension
> Middleware has a mechanism for mapping associating parent resources to a
> mapped resource, whereas the APIRouter does not have such mechanism.****
>
> ** **
>
> As the controller does not care about how URI paths are mapped on its
> methods, the only thing we probably need to worry about is how to make sure
> that the parent resource id is passed to the controller for the
> sub-resource. To this aim, I would probably define a new controller which
> extends the base one rather than modifying quantum.api.v2.base.Controller.
> ****
>
> Btw, there is of course the hackish way of skipping base.create_resource
> and passing to ResourceExtension an object providing implementation for the
> appropriate methods. I am totally sure you're aware of this option too, but
> I would consider it only a last resort.****
>
> ** **
>
> ****
>
> ****
>
> And also how do you guys think should this improvement be done as a
> separate patch?****
>
> ** **
>
> Separate patches in these cases are always preferred. ****
>
> ****
>
> ****
>
> Thanks,****
>
> Oleg****
>
> ****
>
> *From:* Youcef Laribi [mailto:Youcef.Laribi at eu.citrix.com]
> *Sent:* Wednesday, November 14, 2012 11:03 PM****
>
>
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [quantum] Quantum extension framework issue
> ****
>
> ****
>
> Oleg,****
>
> ****
>
> The “/pools/{pool_id}/health_monitors” REST resource is intended to be a
> collection sub-resource of the “/pools/{pool_id}” resource, so if the
> Quantum WSGI framework can be improved to support REST sub-resources that
> would be better and cleaner.****
>
> ****
>
> Youcef****
>
> ****
>
> ****
>
> *From:* Salvatore Orlando [mailto:sorlando at nicira.com]
> *Sent:* Wednesday, November 14, 2012 10:00 AM
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [quantum] Quantum extension framework issue
> ****
>
> ****
>
> Hi Oleg,****
>
> ****
>
> When I read your first email, I had the same impression as Dan.****
>
> health_monitors look more like a subresource than an action. ****
>
> ****
>
> The WSGI framework at the moment is not able to manage subresources; this
> does not mean we cannot improve it though. Nevertheless, in this case the
> route mapping is not performed by the API classes in quantum/api, but by
> the extension manager. I think there should already be a way for specifying
> parent resources with extensions, but that needs to be explored.****
>
> ****
>
> It seems however that you are now trying to map operations on health
> monitors using distinct member actions (add_health_monitor,
> get_health_monitors). This is similar to what happens with the L3 API for
> router interfaces.****
>
> However, it seems the original idea behind the API design was to treat
> health_monitors as an explicit collection, which would also be probably a
> more 'restful' way of doing it. I think ultimately the question should be
> directed to Youcef and the team which contributed to the design of the
> LBaaS API.****
>
> On 14 November 2012 17:18, Oleg Bondarev <obondarev at mirantis.com> wrote:**
> **
>
> Hi Dan,****
>
> Thanks for your comment here. ****
>
> Just wanted to correct a mistake in my first email: of course there can’t
> be a dict with duplicate keys. The idea was to use list of pairs, like:***
> *
>
> member_actions = [{“health_monitors”: “GET”}, ****
>
> {“health_monitors”: “POST”}]****
>
> to have an ability of using same function name with different request
> actions. Initially I thought that the framework provides such ability but
> does not dispatch requests correctly. I was wrong.****
>
> Actually there is no issue with the framework as it assumes using unique
> action names for different request methods. ****
>
> ****
>
> I believe we should update LBaaS REST API doc and use
> “get_health_monitors”, “add_health_monitors”, etc. to fit in the framework.
> ****
>
> ****
>
> Thanks,****
>
> Oleg****
>
> ****
>
> *From:* Dan Wendlandt [mailto:dan at nicira.com]
> *Sent:* Wednesday, November 14, 2012 7:27 PM
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [quantum] Quantum extension framework issue
> ****
>
> ****
>
> Hi Oleg,****
>
> ****
>
> Folks from the API-subteam can correct me, but I believe this use model is
> outside of what the API framework was trying to enable with "actions". The
> idea is that you use POST/DELETE to create an delete API "resources" (which
> actually have UUIDs, for example, the "pool" in your example below) and
> then do a PUT to an "action" to cause some kind of change that you can
> affect on a resource (e.g., "add_health_monitor" or
> "remove_health_monitor"). It sounds like what you are proposing is more
> treating "health_monitors" almost as a "sub-resource", which is not really
> what the "actions" stuff was designed for. ****
>
> ****
>
> I haven't been deeply involved in the LBaaS api design discussion though,
> so I'd also like to hear from Salvatore, et al. on the API sub-team.****
>
> ****
>
> Dan****
>
> ****
>
> ****
>
> On Wed, Nov 14, 2012 at 6:05 AM, Oleg Bondarev <obondarev at mirantis.com>
> wrote:****
>
> Hi guys,****
>
> ****
>
> While working on the API extension for LBaaS I didn’t find a way to use
> custom member actions if they have the same name and differ only by request
> method, for example****
>
> ****
>
> List all health monitors of a specific pool: GET
> /pool/pool_id/health_monitors****
>
> Associate health monitors with a pool: POST /pool/pool_id/health_monitors*
> ***
>
> ****
>
> In quantum extension framework we pass “health_monitors” as member
> actions for a controller (quantum.api.v2.base.create_resource())****
>
> ****
>
> member_actions = {'health_monitors': 'GET',****
>
> 'health_monitors': 'POST'}****
>
> ****
>
> controller = base.create_resource(collection_name,****
>
> resource_name,****
>
> plugin, params,****
>
> member_actions=member_actions)****
>
> ****
>
> According to the Controller implementation it dispatches all custom member
> actions to its plugin attr:****
>
> ****
>
> def __getattr__(self, name):****
>
> if name in self._member_actions:****
>
> def _handle_action(request, id, body=None):****
>
> return getattr(self._plugin, name)(request.context, id,
> body)****
>
> return _handle_action****
>
> else:****
>
> raise AttributeError****
>
> ****
>
> Where request.context is of type quantum.context.Context and does not
> contain info about request method.****
>
> As a result there is no way to distinguish two custom actions in the
> plugin. ****
>
> Is it an issue in the framework?****
>
> ****
>
> Possible solution may be in concatenation of request method and action
> name (“get_health_monitors”, “post_health_monitors”) in a controller before
> dispatching them to a plugin.****
>
> What do you think? ****
>
> ****
>
> Thanks,****
>
> Oleg****
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev****
>
>
>
> ****
>
> ****
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt ****
>
> Nicira, Inc: www.nicira.com****
>
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~****
>
> ****
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev****
>
> ****
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev****
>
> ** **
>
>
> _______________________________________________
> OpenStack-dev mailing list
> 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/20121116/c8295285/attachment.html>
More information about the OpenStack-dev
mailing list