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. -Bob > > Thanks, > Irena > > -----Original Message----- > From: netstack-bounces+irenab=mellanox....@lists.launchpad.net > [mailto:netstack-bounces+irenab=mellanox....@lists.launchpad.net] On Behalf > Of Robert Kukura > Sent: Friday, June 08, 2012 6:21 PM > To: Dan Wendlandt; 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>> 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> >>> twitter: danwendlandt >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : 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 > 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
