On Thu, May 4, 2017 at 10:58 AM, Ben Pfaff <[email protected]> wrote: > > On Thu, May 04, 2017 at 10:34:38AM -0700, Han Zhou wrote: > > On Thu, May 4, 2017 at 10:05 AM, Ben Pfaff <[email protected]> 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 <[email protected]> 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 <[email protected]> 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. > > I agree that there are inconsistencies in the design. Some are easy to > fix, some are not, and I think that we need to decided which are > important enough to fix.
I am not questioning the fix here (except that the string "neutron" could be something more generic). I am trying to understand why using "name" to store unique ids from client system and putting meaningful names in external_ids was a bad idea. If it is not a bad idea, then may be we can just change the document so that it is not just a human readable name, but can be anything unique from a client system. We can change "names" in all tables to unique index, and then the design will be consistent. I understand this may have impact to existing deployments, but I think it is not a bad idea. Being able to specify the unique id by client is a desirable feature. One benefit is, it makes object creation idempotent in case of timeout and retries. P.S. we are not alone for using "name" as unique id, e.g. https://kubernetes.io/docs/concepts/overview/working-with-objects/names/ Of course a namespace mechanism would be better. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
