Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121114/6aa47972/attachment.html>