Hi all, We currently have a problem with Address_Set in networking-ovn (and potentially other technologies using OVN as backend) which *maybe* could be fixed together with this idea of a new "port set" (a.k.a macro set).
The problem is bit tricky but it shows as a race condition between creating and deleting ports in Neutron. That is, deleting a port in Neutron will result in the IP address of that port to be removed from an address set, but at the same time, if another request to create a port overtaking the same IP address of the port being deleted is issued, depending on which order things are committed it could result in the address set to not contain the new port IP address. Here's a bug ticket describing the problem in more detail: https://bugs.launchpad.net/networking-ovn/+bug/1611852 The reason why it happens is because we don't have a direct relationship between the addresses in an address set and the ports that those addresses belongs to. So, if we create this relation we might end up having both ports and addresses present in the Address_Set table which then can be used to fix both of our problems. Here's some ideas: # 1. A new map column We could add a "map" type column called "ports" in the Address_Set table that would look like this in the database: "Address_Set": { "ports": {"port-1-name": {"ipv4_addresses": [...], "ipv6_addresses": [...}} ... } # 2: Add a new way to populate the address set: Instead of directly populating the addresses in an address set where the port relationship isn't clear, we could add two list of ports references (one for each IP version) and have the addresses automatically populated. For example: "Address_Set": { "columns": { "ipv4_ports": {"type": {"key": {"type": "uuid", "refTable": "Logical_Switch_Port", "refType": "weak"}, "min": 0, "max": "unlimited"}} "ipv6_ports": {"type": {"key": {"type": "uuid", "refTable": "Logical_Switch_Port", "refType": "weak"}, "min": 0, "max": "unlimited"}} ... } The problem here is that we would pull all addresses from those ports into the address set. The good part is that since it's a weak reference, deleting a port would automatically remove it from the address set. # 3: Allow duplicated addresses in the list If the above options sounds too complicated, maybe we could keep the idea of this email of creating a "Macro_Set" that could be used for both ports and addresses types [0]. But, when the type is set to "address" we could allow duplicated items in the list of elements that way we won't have a problem if one transaction removes one duplicated element in the list. [0] https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/077118.html Any more ideas? Cheers, Lucas On Thu, Feb 15, 2018 at 12:04 AM, Ben Pfaff <[email protected]> wrote: > On Thu, Feb 15, 2018 at 12:36:35AM +0100, Daniel Alvarez Sanchez wrote: >> If we would have the Port_Set we could simply write the match part as >> "outport == $security_group1 && ip4 && ip4.src == 0.0.0.0/0 && tcp && >> tcp.dst == 22" >> and reduce the number of ACLs to 1 per security group rule instead of 1 per >> security >> group rule per port as it is right now. As you can see, we're referencing >> the relevant security group rule in the CMS through the >> neutron:security_group_rule_id >> key in the external_ids column so we would reduce all ACLs which correspond >> to >> the same SG rule to just 1. > > OK, that matches up with what Han says. Han is going to rebase the > "port set" patches, so I think we'll have a solution for this soon after > that. > _______________________________________________ > discuss mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
