Ask Your Question
0

Quantum data model

asked 2011-07-01 10:46:21 -0600

salvatore-orlando gravatar image

The aim of this question is to get people to think about the "Core" quantum data model.

Quantum has currently two "interfaces" which require a "contract": - the 'public' interface, i.e.: the API - the plugin interface

While the API specification defines the contract for the public interface, the DB model abstract base class for quantum plugins (quantum.quantum_plugin_base.QuantumPluginBase) define the contract for the plugin interface.

Currently, these two contracts are sligthly different, for two reasons: 1 - the attachment is a resource of its own in the API, while just an attribute of the Port resource in the db model 2 - Several attribute names differ (e.g.: net-id vs uuid or net-name vs name)

Ideally, these contracts reflect the same data model. This will also be helpful and avoid us doing conversions from db model to API model as we currently do in the plugins.

Any suggestion?

edit retag flag offensive close merge delete

3 answers

Sort by ยป oldest newest most voted
0

answered 2011-07-07 13:55:12 -0600

salvatore-orlando gravatar image

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.

edit flag offensive delete link more
0

answered 2011-07-06 22:29:34 -0600

salvatore-orlando gravatar image

Hi Somik, Please see my replies inline.

-----Original Message----- From: bounces@canonical.com [mailto:bounces@canonical.com] 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 (https://answers.launchpad.net/quantum...)

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 ... (more)

edit flag offensive delete link more
0

answered 2011-07-06 17:06:16 -0600

somikbehera gravatar image
  • 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.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2011-07-01 10:46:21 -0600

Seen: 59 times

Last updated: Jul 07 '11