Ping :) Reviews/comments appreciated. Thanks, Brad
On Tue, Sep 27, 2011 at 9:29 AM, Brad Hall <b...@nicira.com> wrote: > I've created a branch to address this here: > https://review.openstack.org/#change,665 > > Currently I've only add param dicts to the create calls but maybe it > makes sense to do it for the update calls as well. I'm not terribly > happy about changing the plugin interface as this will break any > plugins that aren't in the tree .. if anyone has other ideas that > would be appreciated. Comments/suggestions/etc appreciated. > > Thanks, > Brad > > On Fri, Sep 23, 2011 at 12:04 AM, Ying Liu (yinliu2) <yinl...@cisco.com> > wrote: >> Hi Brad, >> >> I agree with you. >> >> For extension framework, its functionality only provides us mechanism to >> get extended attributes into request data, which is done as the example >> illustrated. However, to pass the data to the plugin for further >> processing, we need either modify existing action's parse_request_param >> or having flexible param structure, eg. (key, value) pair. We actually >> proposed this earlier as it makes extension much easier. >> >> Just my 2 cents. >> >> Best, >> Ying >> >> >> >> >>> -----Original Message----- >>> From: netstack-bounces+yinliu2=cisco....@lists.launchpad.net >>> [mailto:netstack-bounces+yinliu2=cisco....@lists.launchpad.net] On >>> Behalf Of Brad Hall >>> Sent: Thursday, September 22, 2011 3:20 PM >>> To: netstack@lists.launchpad.net >>> Subject: [Netstack] Data extensions in quantum >>> >>> Hello Netstackers, >>> >>> I've been working with the extensions framework lately and wanted to >>> know how data extensions are supposed to work. What I want to do is >>> something like this: >>> >>> A hypothetical device that I'm writing a plugin for has a property on >>> the port called "foo" and I want to be able to create a port giving >>> "foo" a value. So based on the examples in tests/test_extensions.py I >>> made an extension that contains the following: >>> >>> @classmethod >>> def get_request_extensions(self): >>> def _foo_handler(req, res): >>> data = json.loads(res.body) >>> data[foo] = req.GET.get('foo') >>> res.body = json.dumps(data) >>> return res >>> >>> req_ext = extensions.RequestExtension('POST', >>> '/tenants/:(tenant_id)/networks/:(network_id)/ports', >>> _foo_handler) >>> return [req_ext] >>> >>> Then I can use: >>> >>> POST /v1.0/tenants/<tid>/networks/<nid>/ports (body = {'foo': 'bar'}) >>> >>> The problem is that there is no way (currently) to propagate 'foo' to >>> the create_port call. The port ops_param_list only has port-state so >>> parse_request_params won't allow my 'foo' .. and even if it did the >>> create_port call only picks out the params it knows about (port-state) >>> and sends those directly to plugin::create_port(). >>> >>> What it seems like we need: >>> >>> 1) For parse_request_params we should add any extra params to the >>> result dictionary. >>> 2) {create,update}_{port,network}() calls should just send a params >>> dict as an argument to the plugin create/update function instead of >>> sending the params like port-state as explicit arguments. >>> >>> Does this make sense? Please let me know if I'm thinking about this >>> all wrong or if there is a different way this is supposed to be used. >>> >>> Thanks, >>> Brad >>> >>> -- >>> Mailing list: https://launchpad.net/~netstack >>> Post to : netstack@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~netstack >>> More help : https://help.launchpad.net/ListHelp >> > -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
