On Tue, Jan 9, 2018 at 3:12 AM, Daniel Alvarez Sanchez <[email protected]> wrote: > > Thanks Ben, Han, Miguel. > > > On Tue, Jan 9, 2018 at 11:59 AM, Miguel Angel Ajo Pelayo < > [email protected]> 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. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
