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
