On Thu, May 04, 2017 at 11:14:01AM -0700, Han Zhou wrote: > 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.
It was a bad idea because it was documented to be a human-friendly name. That's all. > 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
