Comment 2 for bug 1881316

We have a working fix for this issue here [1]. However, we are no longer convinced that
the code complexity introduced by the change justifies its benefits. Reasons for that are:

1) More places for a bug to live;
2) Default egress rules work just fine to give VMs access to dhcp and metadata; so this is
   an unnecessary burden in memory and configuration for most use cases;
3) If the operator wants total control over egress rules, implicitly adding SGR behind the
   scenes is exactly what we should _not_ do.

Lastly, just a note that this is a slight departure from the default behavior that one gets
when using ml2/ovs. Even though mls/ovs adds no 'implicit' rules for allowing vms to reach
metadata, it does add the dhcpv4 rules. When using ml2/ovn, operators will need to do add the
rules on his/her own. It would look along these lines:

   # Allow VM to contact dhcp server (ipv4)
   openstack security group rule create --egress --ethertype IPv4 --protocol udp --dst-port 67 ${SEC_GROUP_ID}
   # Allow VM to contact metadata server (ipv4)
   openstack security group rule create --egress --ethertype IPv4 --protocol tcp --remote-ip 169.254.169.254 ${SEC_GROUP_ID}

   # Allow VM to contact dhcp server (ipv6, non-slaac). Be aware that the remote-ip may vary depending on your use case!
   openstack security group rule create --egress --ethertype IPv6 --protocol udp --dst-port 547 --remote-ip ff02::1:2 ${SEC_GROUP_ID}
   # Allow VM to contact metadata server (ipv6)
   openstack security group rule create --egress --ethertype IPv6 --protocol tcp --remote-ip fe80::a9fe:a9fe ${SEC_GROUP_ID}

[1]: https://review.opendev.org/#/c/733033/