[ovs-dev] [PATCH] ovn-northd: Avoid duplicate logical flows in SB db

[Han Zhou]

On Tue, Jan 9, 2018 at 3:12 AM, Daniel Alvarez Sanchez <dalvarez at redhat.com>
wrote:
>
> Thanks Ben, Han, Miguel.
>
>
> On Tue, Jan 9, 2018 at 11:59 AM, Miguel Angel Ajo Pelayo <
> majopela at redhat.com> wrote:
>
> > You're probably right, it's probably not worth increasing the complexity
> > of ovn-northd when we can check this in the low level, and suppress
> > the final OpenFlow duplicates, the code for that is already there,
> > and working.
> >
> > An alternate an not very intrusive approach would be lowering the
> > log level of the duplicate flow messages to DEBUG instead of INFO.
> >
> > Let me recap a bit. We need this because it's the best way
> > we found on the db-consistency effort for networking-ovn, making
> > the security group rules a 1:1 with ACLS for ports, which sometimes
> > will mean that we have a duplicate ACL.
> >
> > It happens when you have a port attached to several security groups
> > with equivalent rules:
> >
> >
> > sg-web:
> >      ingress tcp port 80
> >      ingress tcp port 22
> >
> > sg-db:
> >     ingress tcp port 1234
> >     ingress tcp port 22
> >
> >
> > port-A:
> >    security groups: sg-web + sg-db
> >
> >
> > Until now, we were deduplicating the "ingress tcp 22" acl resulting
> > of the two groups. But then tracking integrity/consistency of neutron_db
> > vs ovn-nb explodes in complexity. (dalvarez can probably explain
better.)
> >
> > Yes, your explanation is quite precise  and I elaborated a bit
> more in the 'annotation' part in the patch.
>
> As Miguel says, we need some way to map OVN resources to Neutron
> ones so we're basically using the external_ids field to map an ACL to the
> corresponding OpenStack security group rule. As Han suggests, we could
> add multiple sg_rule_id's to the external_ids field but that would be
> race-condition
> prone and will add complexity to the networking-ovn side. Especially when
we
> eventually want to move over to a model where we have ACLs per SG per
> rule and not per SG per rule per port.

Agree. Simplicity is preferred. Thanks for the detailed explaining.