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
