[ovs-dev] [PATCH 2/3] expr: Add address set support.

[Russell Bryant]

On Mon, Apr 11, 2016 at 11:50 AM, Ben Pfaff <blp at ovn.org> wrote:

> On Tue, Apr 05, 2016 at 05:24:18PM -0400, Russell Bryant wrote:
> > Update the OVN expression parser to support address sets.  Previously,
> > you could have a set of IP or MAC addresses in this form:
> >
> >     {addr1, addr2, ..., addrN}
> >
> > This patch adds support for a bit of indirection where we can define a
> > set of addresses and refer to them by name.
> >
> >     address_set(name)
> >
> > A future patch will expose the ability to define address sets for use.
> >
> > Signed-off-by: Russell Bryant <russell at ovn.org>
>
> Thanks for working on this.  I have a couple of high-level comments.  I
> haven't reviewed the details yet; I'll plan to do that after we've
> discussed the high level.
>

Sure, thanks for the feedback!


> First, I'd prefer to generalize slightly.  I believe that, with this
> patch, one can write "field == {a, b, c}" or "field == address_set(x)".
> However, I think that it would be nicer if one could write, e.g. "field
> == {a, b, address_set(x), address_set(y), c}".  Could you add that
> feature?
>

Sounds good to me.


> Second, one of my design goals for the expression language was to avoid
> reserved words, so that the language itself, at least, would not
> restrict the choice of field names.  Also, "address_set" is a pretty
> long name, making it somewhat undesirable; I wouldn't want to type it
> very often.  Can you think of a different syntax that would avoid
> reserved words?  For example, one of the following as a substitute for
> address_set(name) might be reasonable:
>
>         $name
>         @name
>         [name]
>         <name>
>         name()


Sure, I can do that.  I don't have a strong preference.  My initial
reaction is to go with $name, though.

-- 
Russell Bryant