[openstack-dev] [quantum] Quantum extension framework issue

Oleg Bondarev obondarev at mirantis.com
Wed Nov 14 16:18:18 UTC 2012


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
~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121114/30afbbf3/attachment.html>


More information about the OpenStack-dev mailing list