While I understand the reasons for which the RequestExtensions scheme might be preferred over the resource extension one, I was wondering whether assigning namespaces to attributes could be a solution to the XML issue. This would clearly separate "core" attributes from extended ones.
Bob, can you share more information concerning the problem you're having with RequestExtensions and XML? I know it might be trivial, but I've not been following the evolution of the code base in the past months, so I'm a bit "rusty" at the moment. Salvatore On 11 June 2012 00:44, Dan Wendlandt <d...@nicira.com> wrote: > Adding main openstack list, as hopefully someone there can common on > implementing Request Extensions using XML. > > I personally think that Request Extensions are a cleaner approach, but it > would seem silly to claim support for two serialization types, but expose > some API extension that work only with one of those types. > > Dan > > On Fri, Jun 8, 2012 at 8:19 AM, Robert Kukura <rkuk...@redhat.com> wrote: > >> 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 >> >> > > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dan Wendlandt > Nicira, Inc: 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
