[openstack-dev] 答复: [quantum] Quantum extension framework issue
Leon Cui
lcui at vmware.com
Fri Nov 16 09:21:17 UTC 2012
I agree. HealthMonitor is the top class object in the resource model.
Mapping to the API, it should be the top resource in URL.
Thanks
Leon
·¢¼þÈË: Oleg Bondarev [mailto:obondarev at mirantis.com]
·¢ËÍʱ¼ä: 2012Äê11ÔÂ16ÈÕ 17:12
ÊÕ¼þÈË: Youcef.Laribi at eu.citrix.com; 'OpenStack Development Mailing List'
Ö÷Ìâ: 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]
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 ¨C 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121116/7abac99a/attachment.html>
More information about the OpenStack-dev
mailing list