Hi Salvatore,

Overall, I am in line with your thinking and I think thats a good  way to
proceed.

Rest inline.

On Mon, Aug 22, 2011 at 12:43 PM, Salvatore Orlando <
<email address hidden>> wrote:

> Hi Somik,
>
> thanks for your review.
>
> I understand your concerns about different the different data structures in
> northbound/southbound interfaces. After all, those are exactly the concerns
> I had when we discussed a uniform data model for the API and the plugin
> interface a few weeks ago, and I thought we concluded that the API and the
> plugin interface represented two distinct interfaces.
>
> If we decide to unify these interface, I'd like to use the current API spec
> as a guideline for changing the plugin interface and not vice-versa, as I
> would like to keep Quantum API as close as possible the ones exposed by
> Openstack and other services in the ecosystem. However, this is not a
> "conditio sine qua non" for me.
>
> You did pretty well in summarizing the differences between northbound and
> southbound interfaces, I would also add the following:
> 1) net-id --> id
> 2) port-id --> id
> 3) port-state --> state
> But I have to agree the attachment-id thing you noticed in your comment #2
> is actually a bug, which is due to the fact that the FakePlugin does not
> implement very well the plugin interface. API code, FakePlugin, and unit
> tests will be fixed accordingly.


> If we want the northbound and southbound interface to have the same shape,
> then having two interfaces (API and quantum_plugin_base) is not a good idea.
> We can just decide that the plugin interface is "THE" interface, and the
> only responsibility of the API layer is converting data structures into the
> appropriate format; or we can do the opposite. Either way, plugins or
> clients will be affected.
>
>
[SB] I agree that API layer can convert to the quantum_plugin_base -> API
format. Since this change is an API change, we can't really prevent API
clients from getting affected. But, if we don't have pressing need to change
quantum_plugin_base then the atleast plugins wont be affected, which would
be good for this late stage change.


> But, at this stage, I don't think  we really need to unify these
> interfaces. Plugin implementors will talk the language of the plugin
> interface, while API users will talk the language of the API interface. The
> API layer will "translate" between these two languages (after all it is not
> a big effort, as it can be seen from the view builders, which are very small
> modules). Another advantage of separating interfaces is that the API can
> evolve indepedently of the plugin interface, and vice-versa; for instance,
> in the future, object ownership information, fetched from the identity
> service, could be added to API data structures without interfering at all
> with the plugin interface.
>
>
[SB] I totally agree with this line of thinking and this would be a great
way to proceed. This approach causes least disruption and provides greatest
flexibility.


> Please let me know what do you think of my proposal.
> I'm totally open to unify API and quantum_plugin_base; my proposal of
> keeping the interfaces separate arises from the considerations reported
> above.
>
>
[SB] Unification will take lot more effort and break both - plugins and
clients, so I believe your non-unified approach as described above is best
as it causes less disruption and still provides an API that fits in with the
OS API ecosystem.


> Thanks again,
> Salvatore
>
>

-- 
Somik Behera | Nicira Networks, Inc. | <email address hidden> <email address hidden> |
office: 650-390-6790 | cell: 512-577-6645