Hi Ying, I too think the approach proposed by Jorge will avoid clashes between different extensions.
I don't have anything in principle against extending core API entities. My only concern is "portability" of client apps. If I write my application using the core API, and I get extended attributes in responses (or I'm supposed to specify extended attributes in requests), then I cannot guarantee that my client app continues to work when the someone swaps RAX-PIE with another extension. This might imply that client applications should somehow be aware of extensions. For instance, I would structure the previous example as follows: XML: <image xmlns="http://docs.rackspacecloud.com/servers/api/v1.0"; id="1" name="CentOS 5.2" serverId="12" updated="2010-10-10T12:00:00Z" created="2010-08-10T12:00:00Z" status="ACTIVE" /> <RAX-PIE:image xmlns:RAX-PIE="http://docs.rackspacecloud.com/servers/api/ext/pie/v1.0"; RAX-PIE:id="ext_res_id" RAX-PIE:ref-id="1" RAX-PIE:shared="true" /> JSON: { "image" : { "id" : 1, "name" : "CentOS 5.2", "serverId" : 12, "updated" : "2010-10-10T12:00:00Z", "created" : "2010-08-10T12:00:00Z", "status" : "ACTIVE", } } { "RAX-PIE:image" : { "id" : "ext_res_id", "ref-id" : "1", "RAX-PIE:shared" : true } } In this way a client for the Core API will always get the responses the core API is supposed to receive, whereas a client specifically written for RAX-PIE extension will retrieve the "extended" image resource and then the original image resource through the ref-id attribute. Anyway, I don't have a very strong opinion on this topic, and I also agree that allowing direct extension of resources has its own benefits. If the majority agrees on allowing resource extensions, then I will be happy to have them :). It would be good to receive feedback from Tyler and the other guys who worked on the client library as well. Cheers, Salvatore From: Ying Liu (yinliu2) [mailto:yinl...@cisco.com] Sent: 03 August 2011 00:46 To: Salvatore Orlando; Dan Wendlandt; netstack@lists.launchpad.net Subject: RE: [Netstack] [Merge]lp:~raxnetworking/quantum/api_extensions into lp:quantum Hi Salvatore, I agree with you and Dan on data extension. It provides flexibility can enrich core resources' attributes. Regarding to the possible clashes among different plug-ins, Jorge has proposed using Vendor ID and alias. Here is his proposal: (having both xml and json example) Add additional Data: - In XML, attribute may be added to elements so long as they are in the extension namespace - In XML, Elements added after last element assuming "Unique Particle Attribution" is not violated - In JSON, use alias followed by a colon ":" <image xmlns="http://docs.rackspacecloud.com/servers/api/v1.0"; xmlns:RAX-PIE="http://docs.rackspacecloud.com/servers/api/ext/pie/v1.0"; id="1" name="CentOS 5.2" serverId="12" updated="2010-10-10T12:00:00Z" created="2010-08-10T12:00:00Z" status="ACTIVE" RAX-PIE:shared="true" /> { "image" : { "id" : 1, "name" : "CentOS 5.2", "serverId" : 12, "updated" : "2010-10-10T12:00:00Z", "created" : "2010-08-10T12:00:00Z", "status" : "ACTIVE", "RAX-PIE:shared" : true } } Best, Ying From: netstack-bounces+yinliu2=cisco....@lists.launchpad.net [mailto:netstack-bounces+yinliu2=cisco....@lists.launchpad.net] On Behalf Of Salvatore Orlando Sent: Sunday, July 31, 2011 5:34 PM To: Dan Wendlandt; netstack@lists.launchpad.net Subject: Re: [Netstack] [Merge]lp:~raxnetworking/quantum/api_extensions into lp:quantum Replies inline. Cheers, Salvatore <SNIP> >From the code it seems the implementation allows for defining new resources, >extending quantum core API resources, and adding actions to Core API >resources. It was my understanding that in the NetStack meeting we kind of >agreed extensions will not alter core API resources. For instance a 'QoS' attribute for a port should have not been defined as an 'extended' attribute of the core API port object, but within a "port-profile" extended resources, which would then be bound to the core API port object. This does not mean I'm not willing to accept code that extends core API resources; I just want to clarify what we decided in our meetings. I think this is a key point to discuss, thus, I'm moving it to the nestack list. I do not remember us reaching any official decision on whether or not "core" API objects (right now, "network" and "port") could or could not be modified using "data extension". I remember an IRC discussion where this was suggested as an option though. I think this is great design discussion to have on the netstack list. Here are a couple thoughts to get the ball rolling: - Data extension of core objects will probably lead to the most intuitive API from a user perspective, as there can be a smaller number of unique objects to deal with. - Data extension of core objects may complicate API internals + validation, as the core API code no longer knows exactly what is or is not valid within a network or port object. - I believe nova currently allows data extension of core objects, and our bias is to "do as OpenStack does" unless we have a strong reason to differ. - My goal is that people will propose extensions with the goal of them being incorporated as part of the "core" eventually. Thus, it would seem logical that they could implement the extension so that it is exposed the same way it would be exposed as part of the core API (i.e., data extension is an option). - It is important that we make it easy for API clients to validate that a particular extension is supported by a Quantum instance. I believe this is possible both with and without data extension, but doing so may be simpler without data extension. Thoughts? [Salvatore] As Dan says, allowing data extension (and I think behaviour extensions) as well to Core API resources, could make the API more intuitive; moreover this will also enhance the process of moving extended attributes/actions to the core API as quantum evolves. I'm not against this, but I just want to be sure that we thoroughly think about implications on client applications. Let's imagine we have two plugins, "foo" and "bar", both of them defining an attribute with the same name, say "whatever", for the core API "port" object. A client aware of the "foo" plugin extensions would look for this attribute and use it. If the same client is used against a version of Quantum running the "bar" plugin, it would probably fail. Namespaces provide a natural solution, as "foo:whatever" would be different from "bar:whatever". Is there a way to specify namespaces in json (please forgive my ignorance)? Another way of looking at this problem is that the two plugins can extend the "port" resource by defining extended resources, say "foo_port" and "bar_port". These resources would contain all extended attributes and actions, plus a reference (maybe a link) to the corresponding base resource defined by the core API. Dan p.s. I also think this is related to https://bugs.launchpad.net/quantum/+bug/814518, which is a unit test that fails because we currently do not reject request bodies with "extra" bogus fields. Whether we want to add that kind of validation probably depends on the answer to the above question. Agreed. This bug causes a failures in two unit tests: create_port_badrequest_xml and create_port_badrequest_json. I think we can fix this bug in an "agnostic way" by making sure a 400 error is returned if the body contains something which is definitely not a port. For instance: <port> <port-state>DOWN</port-state> <foo:extattribute>somevalue</foo:extattribute> </port> Should be considered a valid request, whereas <someotherrubbish> <rubbish-element>rubbish-value</rubbish-element> </someotherrubbish> Should trigger the 400 error.
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
