On 06/11/2012 11:28 AM, Dan Wendlandt wrote: > > > On Mon, Jun 11, 2012 at 6:15 AM, Robert Kukura <rkuk...@redhat.com > <mailto:rkuk...@redhat.com>> wrote: > > On 06/10/2012 03:19 PM, Irena Berezovsky wrote: > > Hi Robert, > > May I add to your question also considerations regarding network > creation - POST operation? > > I may be wrong in my understanding, but it seems to me that in > case of RequestExtension it will be possible to create Provider > Network via a single call. > > In case of ResourceExtension it will require 2 calls; one for > network creation and second for "provider" attributes setting for > previously created network. Am I right? > > In case of ResourceExtension Plugin on network creation should > behave differently for "provider" and other(virtual) network, i.e. > skip VLAN allocation. Seems that Plugin should be aware about > Network type already during network creation. > > What do you think? > > Hi Irena, > > I'd like to avoid this sort of two-step resource creation process. > Adding new optional arguments to the existing POST operation that > creates a new resource such as network seems to work, at least with > JSON. I haven't looked into XML support for this yet. These arguments > get passed through to the plugin as kwargs. Their names should use the > extension's namespace prefix, but otherwise I don't think any explicit > support in the extension framework is involved. > > > Just shoving values into a post and having them passed in as kwargs > works (we've done this in the past), but what I don't like about that > approach is that if we don't actually use an extension, there's no good > way for an API user to query the set of supported extensions and see if > that extension is running. Likewise, if extra arguments are passed into > the plugin as kwargs, an API might pass them in and believe they were > accepted, when in fact they were just ignored by the plugin.
Good points Dan. I'm definitely exposing the provider-networks functionality as a proper extension so it can be queried, etc. As I mentioned, the extended request and response body attributes will belong to the provider extension namespace. Regarding the "ignored by the plugin" point, I've been thinking the extension should define a provider:network_type argument. Any plugin supporting the provider extension would be required to raise an exception if the network_type argument indicated a type that it didn't support. Each value of network_type would correspond to a set of additional arguments (i.e. provider:vlan_id) that a plugin supporting that network_type would need to honor. The default value for network_type would be 'virtual', indicating the standard quantum functionality is desired. Initial network_type values would be 'virtual', 'vlan', and 'flat', and maybe 'gre' for openvswitch. Does something like this make sense? -Bob > > Dan > > > > -Bob > > > > > Thanks, > > Irena > > > > -----Original Message----- > > From: netstack-bounces+irenab=mellanox....@lists.launchpad.net > <mailto:mellanox....@lists.launchpad.net> > [mailto:netstack-bounces+irenab > <mailto:netstack-bounces%2Birenab>=mellanox....@lists.launchpad.net > <mailto:mellanox....@lists.launchpad.net>] On Behalf Of Robert Kukura > > Sent: Friday, June 08, 2012 6:21 PM > > To: Dan Wendlandt; netstack@lists.launchpad.net > <mailto:netstack@lists.launchpad.net> > > Subject: [Netstack] Provider Networks extension advice (was Re: > [Openstack] question on get_network_details api call) > > > > Dan, Netstackers, > > > > I need some advice ASAP so I can proceed with the provider-networks BP > > (https://blueprints.launchpad.net/quantum/+spec/provider-networks) > > implementation. This BP will be implemented using a "provider" > extension that adds a number of optional attributes (eg. vlan tags) > to the core network resource. These attributes will be settable by > and visible to those with admin rights. > > > > The main decision I'm looking for advice on is whether to > implement this extension as a RequestExtension or as a > ResourceExtension. See the email quoted below for details. > > > > If implemented as a RequestExtension, these provider attributes > would be returned along with the core attributes from "GET > /tenants/{tenant_id}/networks/{network_id}.json", and potentially > from all API actions that return the core attributes. > > > > If implemented as a ResourceExtension, the provider attributes > would be accessed from a separate sub-resource, such as "GET > /tenants/{tenant_id}/networks/{network_id}/provider.json". > > > > As Dan suggested below, I think it would be preferable to extend > the core resource itself rather than define a new sub-resource. This > would mean using the RequestExtension approach. The issue with this > is that I see no way to support XML with this approach, but the > ResourceExtension approach can support both JSON and XML. > > > > Is the RequestExtension approach preferable? Is it acceptable even > if it cannot (currently) support XML? Or is there a way to extend > the XML using a RequestExtension that I'm missing? > > > > Thanks, > > > > -Bob > > > > > > On 06/07/2012 05:19 PM, Robert Kukura wrote: > >> On 06/02/2012 01:56 PM, Dan Wendlandt wrote: > >>> Hi Irena, Bob, Salvatore, > >>> > >>> Just catching up the thread, and looping the netstack and openstack > >>> lists in as well, as this info is general useful in my opinion. > >>> > >>> Our model with Quantum, like Nova, is that it is definitely ok to > >>> extend the content of a core object with additional attributes. > >>> These attributes should be formatted properly as extended attribute, > >>> so that the "key" of the attribute is > >>> <extension-alias>:<attribute-name> > >>> > >>> This is done pretty commonly within Nova. Two simple examples are: > >>> - nova/api/openstack/compute/contrib/scheduler_hints.py > >>> - nova/api/openstack/compute/contrib/extended_status.py > >>> > >>> I do not believe you need to (or should) modify the view-builder > code > >>> for the core object when you want to add an extended attribute > to it. > >> > >> Thanks Dan! I've now had some success implementing an extension that > >> creates a RequestExtension that adds extended attributes to the > >> response for a core resource. At least with JSON - I have not been > >> able to figure out how to do this for XML, if that is even > possible in quantum. > >> > >>> Instead, the extension framework has you write a wsgi controller > >>> specific to the extension that is inserted as its own stage into the > >>> wsgi request and response processing pipeline. Thus, when the > >>> request is passed in, your code gets a chance to parse the data, and > >>> the the response is passed back, your code gets a chance to add > data to it. > >> > >> The above description sounds more like a ResourceExtension than a > >> RequestExtension. A ResourceExtension introduces a new Controller, > >> whereas a RequestExtension just adds a handler function called by the > >> core's RequestExtensionController. All examples and descriptions I've > >> seen use ResourceExtension to introduce a new type of resource. Are > >> you suggesting this mechanism can also be used to extend an existing > >> core resource? Would this have any advantage over using a > >> RequestExtension? I still don't see any way a ResourceExtension could > >> add extended attributes into an XML response. > >> > >>> > >>> Using the Nova code as example is probably the best bet if you can > >>> find a good example within quantum. Quantum's extension framework > >>> (and several other openstack projects) all use essentially the > same model. > >> > >> The nova and quantum code seem to have diverged significantly. The > >> nova examples use a nova.api.openstack.wsgi.extends decorator on > >> methods of an extension-implemented Controller to do "request > >> extensions", but quantum doesn't have this decorator. Also, nova uses > >> XML templates that are extensible, whereas the > _serialization_metadata > >> in quantum core resources does not seem to be extensible. > >> > >> At this point, quantum's RequestExtension mechanism seems able to do > >> the job for the provider-networks BP, assuming that a JSON-only > >> solution is acceptable. If both JSON and XML support are needed, > then, > >> unless I am missing something, creating a new (sub-)resource using a > >> ResourceExtension (similar to the portstats extension) seems like the > >> only straightforward option. > >> > >> -Bob > >> > >>> > >>> Dan > >>> > >>> > >>> On Sat, Jun 2, 2012 at 8:43 AM, Robert Kukura > <rkuk...@redhat.com <mailto:rkuk...@redhat.com> > >>> <mailto:rkuk...@redhat.com <mailto:rkuk...@redhat.com>>> wrote: > >>> > >>> On 06/02/2012 05:02 AM, Irena Berezovsky wrote: > >>> > Hi, > >>> > Bob, Dan, > >>> > I ran into following wiki page: > >>> > > >>> > > http://wiki.openstack.org/QuantumAPIExtensionsaction=AttachFile&do=view&target=quantum_api_extension.pdf > >>> > > <http://wiki.openstack.org/QuantumAPIExtensionsaction=AttachFile&do=view&target=quantum_api_extension.pdf> > >>> > 'port profile' is exactly what I was looking for to expose > in the > >>> plugin. > >>> > I would like to add the port profile retrieval capability and > >>> contribute the implementation. > >>> > > >>> > Can you please advise if there is any disagreement on > getting it > >>> into core API? Shall I do it via extension? > >>> > Bob, seems that you are dealing with similar issues. > >>> > What do you suggest? > >>> > > >>> > Thanks a lot, > >>> > Irena > >>> > >>> Irena, > >>> > >>> I'm not sure there is any consensus around using a "network > profile" for > >>> this. I did see that document as well as archived discussion > about > >>> defining "port profile" and "network profile" as extensible > collections > >>> of attributes. But the existing "port profile" extension > looks to be > >>> Cisco-specific, and seems to serve a somewhat different purpose. > >>> > >>> My current thinking is that we'd be better off long term > following the > >>> lead of Nova and other projects in supporting "extension > data" within > >>> the existing resources instead of requiring introduction of > a new > >>> resource just to hold plugin-specific attributes. > >>> > >>> But, in the short term, it might make the most sense for > each extension > >>> just to provide its own resource extension with its > attributes. That's > >>> what I'm tentatively planning to do for the provider-network > blueprint, > >>> but would reconsider if there was consensus that either the > "extension > >>> data" support or a more general "network profile" should be > added now. > >>> > >>> -Bob > >>> > >>> > >>> > >>> > >>> -- > >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>> Dan Wendlandt > >>> Nicira, Inc: www.nicira.com <http://www.nicira.com> > <http://www.nicira.com> > >>> twitter: danwendlandt > >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >>> > >> > >> > >> _______________________________________________ > >> Mailing list: https://launchpad.net/~openstack > >> Post to : openst...@lists.launchpad.net > <mailto:openst...@lists.launchpad.net> > >> Unsubscribe : https://launchpad.net/~openstack > >> More help : https://help.launchpad.net/ListHelp > > > > > > -- > > 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, Inc: www.nicira.com <http://www.nicira.com> > twitter: danwendlandt > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
