And here my comments (also posted previously): 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 :). From: Dan Wendlandt [mailto:d...@nicira.com] Sent: 04 August 2011 22:01 To: Salvatore Orlando Cc: Ying Liu (yinliu2); Santhosh Kumar M; netstack@lists.launchpad.net Subject: Re: [Netstack] [Merge]lp:~raxnetworking/quantum/api_extensions into lp:quantum I'm in favor of making a decision on whether we allow data extensions or not before approving this. If the code goes in allowing data extensions, it would be hard to reverse. I personally am in favor of allowing data extensions, but want to make sure there is general agreement. Below are the comments on this that I posted to the list previously. Dan 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. On Thu, Aug 4, 2011 at 1:45 PM, Salvatore Orlando <salvatore.orla...@eu.citrix.com<mailto:salvatore.orla...@eu.citrix.com>> wrote: Hi Ying, Santosh fixed a couple of minor issues I found in the code. In Tuesday's meeting we did not really discuss about whether API extensions should allow to extend core resources as well. However, I do not want to hold up this branch for too long. I just want to be sure that it allows to implement at least a clean separation between namespace as you explained in the email which started this thread. Salvatore > -----Original Message----- > From: Ying Liu (yinliu2) [mailto:yinl...@cisco.com<mailto:yinl...@cisco.com>] > Sent: 04 August 2011 21:09 > To: Salvatore Orlando; Santhosh Kumar M > Cc: netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net> > Subject: RE: [Netstack] [Merge]lp:~raxnetworking/quantum/api_extensions > into lp:quantum > > Hi Santhosh and Salvatore, > > I saw api_extensions merge request is still pending. > Are there any fixes going on? > > Best, > Ying > > > -----Original Message----- > > From: Tyler Smith -X (tylesmit) > > Sent: Thursday, August 04, 2011 12:00 PM > > To: Ying Liu (yinliu2) > > Cc: netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net> > > Subject: Re: [Netstack] > [Merge]lp:~raxnetworking/quantum/api_extensions > > into lp:quantum > > > > Hi Ying, > > > > You (and Salvatore) were right. I checked out the branch, but now I > > get a 500 error: > > > > RoutesException: URL or environ must be provided > > > > I'm looking into fixing it now. Regardless, > > https://code.launchpad.net/~tylesmit/quantum/api-client-add-list- > > extensions > > <https://code.launchpad.net/%7Etylesmit/quantum/api-client-add-list- > > extensions> > > should do it. Once I get my server working to test against I'll send > a > > merge request. > > > > Thanks, > > -Tyler > > > > On 8/4/2011 11:25 AM, Ying Liu (yinliu2) wrote: > > > Hi Tyler, > > > > > > /v0.1/extensions works for me. > > > You can check your quantum.conf file to see whether the extension is > > > configured or not. > > > > > > BTW, this extension framework is not merged with quantum yet. You > > need > > > to directly check out Santosh's branch to use /v0.1/extensions > > > > > > Best, > > > Ying -- 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
