[ovs-dev] [PATCH v2 02/13] ovn-northd: Propagate Neutron datapath names to southbound database.

Han Zhou zhouhan at gmail.com
Thu May 4 17:34:38 UTC 2017


On Thu, May 4, 2017 at 10:05 AM, Ben Pfaff <blp at ovn.org> wrote:
>
> On Wed, May 03, 2017 at 11:43:15PM -0700, Han Zhou wrote:
> > On Wed, May 3, 2017 at 4:55 PM, Ben Pfaff <blp at ovn.org> wrote:
> > >
> > > On Wed, May 03, 2017 at 07:42:46PM -0400, Russell Bryant wrote:
> > > > On Wed, May 3, 2017 at 11:45 AM, Ben Pfaff <blp at ovn.org> wrote:
> > > > > It's much easier to see what's going on in the southbound
database if
> > > > > human-friendly names are available.
> > > > >
> > > > > Really it's too bad that we didn't put the human-friendly name in
> > "name"
> > > > > and the UUID in something like "external_ids:neutron-uuid", but
it'll
> > take
> >
> > Does OVSDB schema support index on map keys inside a column?
>
> No.  For cases where the database needs to maintain uniqueness, a
> dedicated column is needed.  But that is not always the case here.

Yes, it doesn't matter for this patch. I just try to understand what should
be the desired design, if putting neutron-uuid in name was a bad idea. The
case in Neutron plugin (or maybe also in some other CMS systems) is that it
tries to avoid storing any ovn uuid's. When it needs to get corresponding
ovn object, it queries OVN NB by neutron-uuid. At least in
Logical_Switch_Port it seems nature to put it in "name" column, because in
the schema, name is unique index in Logical_Switch_Port, so just act as an
ID, although "name" suggests something else. If we put it in
external_ids:neutron-uuid, it is not indexable. Maybe it is not a big
problem because the "index" here in ovsdb may be not that critical as in
traditional db, because what matters is IDL cache, but still it seems not
right if some unique key can't be indexed. Another thing is, we have the
"name" in most of the OVN tables, some are index (e.g. the one in
Logical_Switch_Port), some are not. This may be confusing, too.


More information about the dev mailing list