[ovs-dev] [PATCH v2 11/13] ovn-trace: Accept human-friendly logical port and datapath names.

[Ben Pfaff]

On Thu, May 04, 2017 at 10:48:58AM -0700, Ben Pfaff wrote:
> On Thu, May 04, 2017 at 02:01:03AM -0700, Andy Zhou wrote:
> > On Wed, May 3, 2017 at 8:45 AM, Ben Pfaff <blp at ovn.org> wrote:
> > > This allows the user to specify these names in a natural way, e.g.
> > > "ovn-trace myswitch 'inport == "myport"' instead of having to specify
> > > whatever UUID or other horrible name the CMS invented.
> > >
> > > Signed-off-by: Ben Pfaff <blp at ovn.org>
> > > ---
> > >  ovn/utilities/ovn-trace.c | 18 +++++++++++++++++-
> > >  1 file changed, 17 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/ovn/utilities/ovn-trace.c b/ovn/utilities/ovn-trace.c
> > > index 7ad7839a4a1a..f4fcb81c9ed3 100644
> > > --- a/ovn/utilities/ovn-trace.c
> > > +++ b/ovn/utilities/ovn-trace.c
> > > @@ -338,6 +338,7 @@ struct ovntrace_datapath {
> > >      struct uuid sb_uuid;
> > >      struct uuid nb_uuid;
> > >      char *name;
> > > +    char *name2;
> > >      uint32_t tunnel_key;
> > >
> > >      struct ovs_list mcgroups;   /* Contains "struct ovntrace_mcgroup"s. */
> > > @@ -354,6 +355,7 @@ struct ovntrace_port {
> > >      struct ovntrace_datapath *dp;
> > >      struct uuid uuid;
> > >      char *name;
> > > +    char *friendly_name;
> > >      char *type;
> > >      uint16_t tunnel_key;
> > >      struct ovntrace_port *peer; /* Patch ports only. */
> > > @@ -432,7 +434,8 @@ ovntrace_datapath_find_by_name(const char *name)
> > >  {
> > >      struct ovntrace_datapath *dp;
> > >      HMAP_FOR_EACH (dp, sb_uuid_node, &datapaths) {
> > > -        if (!strcmp(name, dp->name)) {
> > > +        if (!strcmp(name, dp->name)
> > > +            || (dp->name2 && !strcmp(name, dp->name2))) {
> > >              return dp;
> > >          }
> > >      }
> > > @@ -529,6 +532,8 @@ read_datapaths(void)
> > >                      ? xstrdup(name)
> > >                      : xasprintf(UUID_FMT, UUID_ARGS(&dp->nb_uuid)));
> > >
> > > +        dp->name2 = nullable_xstrdup(smap_get(ids, "name2"));
> > > +
> > >          dp->tunnel_key = sbdb->tunnel_key;
> > >
> > >          ovs_list_init(&dp->mcgroups);
> > > @@ -563,6 +568,8 @@ read_ports(void)
> > >          port->name = xstrdup(port_name);
> > >          port->type = xstrdup(sbpb->type);
> > >          port->tunnel_key = sbpb->tunnel_key;
> > > +        port->friendly_name = nullable_xstrdup(smap_get(&sbpb->external_ids,
> > > +                                                        "name"));
> > >
> > >          if (!strcmp(sbpb->type, "patch")) {
> > >              const char *peer_name = smap_get(&sbpb->options, "peer");
> > > @@ -875,6 +882,15 @@ ovntrace_port_lookup_by_name(const char *name)
> > >          return port;
> > >      }
> > >
> > > +    struct shash_node *node;
> > > +    SHASH_FOR_EACH (node, &ports) {
> > > +        const struct ovntrace_port *port = node->data;
> > > +
> > > +        if (port->friendly_name && !strcmp(port->friendly_name, name)) {
> > > +            return port;
> > > +        }
> > > +    }
> > > +
> > Same general question as the last patch, should we try to detect
> > multiple matches on those user assigned names?  OVSDB does not require
> > them to be unique.
> 
> You're right, it's ultimately more user friendly to detect and report
> multiple matches.  I added code for that.

I posted v3 with this and a few other fixes.