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: netstack@lists.launchpad.net Subject: Re: [Netstack] Changing the update_{network,port} calls On Tue, Oct 18, 2011 at 1:42 PM, Brad Hall <b...@nicira.com<mailto:b...@nicira.com>> 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? 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. 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. 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 : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net> Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com<http://www.nicira.com> | www.openvswitch.org<http://www.openvswitch.org> Sr. Product Manager cell: 650-906-2650 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
