Quantum data model

- QuantumPluginBase is just the contract, DB model may or may not map 1-1 to this contract. While in traditional nova drivers where everything is backed by one DB, what you mention would make sense, in our case we can multiple DB models behind this plugin interface.

- As for the attribute names, I dont see an issue for internal names, for names that are being used as "keys", streamlining them would be a good idea.

- I believe the API naming didn't exist when the Plugin Interface was written, so we could make the argument for changing API names too :) But, in seriousness, I think until we have well defined interfaces, I dont care about names.

- As for attachment being resource of its own or not, thats more around creating a RESTful API but that API mapping breaksdown in the current plugin interface? I am not clear on this one.

Hi Somik,
Please see my replies inline.

> -----Original Message-----
> From: <email address hidden> [mailto:<email address hidden>] On Behalf
> Of Somik Behera
> Sent: 06 July 2011 18:11
> To: Salvatore Orlando
> Subject: Re: [Question #163388]: Quantum data model
>
> Your question #163388 on quantum changed:
> https://answers.launchpad.net/quantum/+question/163388
>
> Status: Open => Needs information
>
> Somik Behera requested more information:
> - QuantumPluginBase is just the contract, DB model may or may not map
> 1-1 to this contract. While in traditional nova drivers where everything is
> backed by one DB, what you mention would make sense, in our case we can
> multiple DB models behind this plugin interface.
>

QuantumPluginBase defines the contract between Quantum and the plugin as concerns the operations the plugin must support and the data the plugin must accept in input.
However this contract is not able to regulate the type of the data returned from the plugin to Quantum (and the type of the input data as well).
I was proposing to use the data model to supply to the lack of regulation on the nature of returned data, as both Quantum and the plugin agree on the same model.

However, it is true that each plugin can implement its own database, and so the adoption of a particular data model as a contract becomes difficult unless plugin implementations adopt, and possibly extend, the data model specified by Quantum.
From previous discussions on this topic I remember a proposal in this direction; frankly, I am not very keen on putting this kind of constraint on plugin implementation, but the fact that the "db" package appears directly under "Quantum" and not under a specific plugin directory made me think it was decided to have a data model every plugin should conform to.

With this in mind, it is my opinion that we have the following alternatives:
1) The plugin implementation will return data according to the API specification. If data returned by the plugin does not follow the API specification, an exception will be raised. This is what the OpenvSwitch plugin currently does;
2) The plugin implementation will return data according to db models classes (i.e.: what you currently find in quantum/db/models.py). If returned data is not an instance of the expected model class an exception will be raised.
3) The plugin returns typed data, where the specification of the type reflects the API specification (for instance a network will have a net-id and net-name fields). We can look at how we can enforce type checking in python using the @returns decorator and possibly the @accepts decorator for input data.

If there is a consensus about having a db model which represents the greatest common divisor across all the plugin, I think it makes sense going for option 2. Otherwise, I would go for option 3, which will probably result in a neater implementation; this will also imply that the current db model should be moved in a plugin specific directory (maybe plugins/openvswitch).

> - As for the attribute names, I dont see an issue for internal names, for
> names that are being used as "keys", streamlining them would be a good
> idea.
>

I don't see issues as well, as long as they are not returned to the Quantum service. However, if the quantum/db package is meant to define models for all plugin, which don't use the same attribute names we use in the API layer? Of course, this question should be ignored if quantum/db is not meant to be a model common to all plugins.

> - I believe the API naming didn't exist when the Plugin Interface was written,
> so we could make the argument for changing API names too :) But, in
> seriousness, I think until we have well defined interfaces, I dont care about
> names.

I'm not a great fan of names too. The only thing I want from them is to be consistent. If we have a "common" db model and we call the network identifier "uuid" in this models, I don't see why we should call it "net-id" in the API.
Again, ignore this comment if there is no intention to have a common db model.

>
> - As for attachment being resource of its own or not, thats more around
> creating a RESTful API but that API mapping breaksdown in the current plugin
> interface? I am not clear on this one.
>

My comment was about the fact that the db model should faithfully reflect the data model defined by the API. This always assuming the current db model is meant to be common to all plugins.

I hope I have clarified enough my point. Probably it is all down to the fact the perhaps that db model is not meant to be common to all plugins, and therefore I'd like to clarify this first.
Then, once we settle down a first quantum release, we could go back to the db and discusses whether Quantum is worth having its own db or not.
Also, I will check with the Atlas guy how they are handling the problem of input parameters and return values for plugin, as they have a model very similar to ours.

> --
> To answer this request for more information, you can either reply to this
> email or enter your reply at the following page:
> https://answers.launchpad.net/quantum/+question/163388
>
> You received this question notification because you asked the question.

I did some experiments and spoke to people working in the Atlas project.

The decorators are of no great help in type checking. I therefore believe the best think we could do is have the plugin return data in the format the API expects them (as the OpenvSwitch plugin currently does), and then make sure in the API returned data conform to the API specification.

As far as the db models are concerned, we need to decide whether we want to have models common to all plugin implementations, or let each plugin provider implement its own schema without any constraint.