Open Stack

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/e3307419/attachment.html>