Sorry for not responding to this sooner.. replies inline.. On Wed, Oct 19, 2011 at 2:48 AM, Salvatore Orlando <[email protected]> wrote: > Thanks Brad for starting the discussion on this important point. > > Some comments inline. > > > > Salvatore > > > > From: netstack-bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net > [mailto:netstack-bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net] > On Behalf Of Dan Wendlandt > Sent: 19 October 2011 01:01 > To: Brad Hall > Cc: [email protected] > Subject: Re: [Netstack] Changing the update_{network,port} calls > > > > > > On Tue, Oct 18, 2011 at 1:42 PM, Brad Hall <[email protected]> wrote: > > Hey Everyone, > > Since the change to make the create() calls take a parameter of k/v > pairs has gotten approval I wanted to propose a change to make the > update calls do the same. The review is here: > https://review.openstack.org/#change,929 .. I've posted this review in > order to get feedback and to have some code as a discussion starting > point. > > This has a few unfortunate consequences: > > 1) Rename_net and set_port_state .. both of these are what we had for > our "update" calls, except they weren't very generic ;) I've changed > the plugin interface to remove these calls and replace them with > generic update_port. This will break any plugins not in the tree :( > > > > I think it might be worth spending some time trying to devise a solution > avoiding plugin breakage when we change the plugin interface. In the same > way in which we strive to achieve backward compatibility on the API, it > probably makes sense to do the same with plugins. > > For instance, we might have a ‘1.0’ plugin interface and a ‘1.1’ interface. > When a plugin is loaded, its configuration file (or a constant in the main > .py file) states the version of the plugin. This way we should be able to > invoke rename_port on plugins compliant with 1.0 interface, and update_port > on plugins compliant with 1.1 interface. > > However, this is just an idea lurking in the back of my mind at the moment; > there are probably several problems I’m not seeing at the moment, especially > as concerns relationships between plugin versioning and API versioning. > > Any thoughts? >
I think its a good idea but not sure we want to go through the effort to do it right now. If anyone feels strongly I can do it but otherwise I'd rather just change the plugins at this point and file an item to add versioning support later. > > 2) The CLI will have to change. Instead of "bin/cli rename_net <tid> > <nid> foo" we'll have to do something like "bin/cli update_net <tid> > <nid> name=foo". Does that seem reasonable? Looking for feedback > here. > > > > this makes sense to me. when doing this, you should take into consideration > the design summit discussion about CLI extensibility, as a particular plugin > may want to introduce more k-v pairs for a network or port. > > > > Agree on changes to CLI. I would also be happy to see a blueprint on CLI > extensibility; this should probably be part of the work on improvements to > the API extensions framework. > Yeah.. I was hoping someone was going to volunteer to submit this blueprint but maybe I'll just do it since I'm breaking stuff anyways :) > > > Salvatore has a proposal out for changing the API to be more like nova > with a better deserialize that will (I think) do the same thing here. > If I'm not mistaken we will still have to change the plugins so if we > decide to go with his proposal we'll have to do this work anyways. > > > > The change I am proposing does not touch the plugin interface at all. It is > about replacing _parse_request_params with a better de-serializer. > I mean, _parse_request_params is good, and Brad’s changes now allow us to > pass any extra parameter into the request body directly to the plugin; > nevertheless I think we will be better off with code which is shared with > nova and possibly other Openstack projects, and therefore likely to become > part of Openstack-commons. > I agree with this completely. Are you planning to work on this? Maybe we can divide up the work some how. > Also note that I didn't change the cisco plugins yet .. but I will. I > just wanted to see if people are OK with this before I go and do that > since it is fairly time consuming. Must be the shear number of tests! > > > > that is a good reason for a task to be time consuming :) > > > > dan > > > > Thanks, > Brad > > -- > Mailing list: https://launchpad.net/~netstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~netstack > More help : https://help.launchpad.net/ListHelp > > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira Networks, Inc. > www.nicira.com | www.openvswitch.org > Sr. Product Manager > cell: 650-906-2650 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thanks, Brad -- Mailing list: https://launchpad.net/~netstack Post to : [email protected] Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
