I don't have yet performed a complete review. Anyway, I was wondering whether we can avoid breaking existing plugins by using **kwargs, and not removing existing parameters
Example: create_network(self, tenant_id, net_name, **kwargs) I also think Ying had another important point on how the API layer should parse information for extended data. Parse_request_params only deal with 'core' structure of resources, and this is something else that needs to be addressed. Salvatore > -----Original Message----- > From: netstack- > bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net > [mailto:netstack- > bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net] On Behalf Of > Brad Hall > Sent: 10 October 2011 23:06 > To: Ying Liu (yinliu2); Dan Wendlandt > Cc: netstack@lists.launchpad.net > Subject: Re: [Netstack] Data extensions in quantum > > 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 -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
