Comment 8 for bug 1978497

The documentation states that the intended behavior is that "packets will be allowed if any one of the firewall groups associated with that Neutron port allows the packet." This is not a true statement, as I demonstrated in my configuration example above. If one group allows the packet, but another group explicitly denies the packet, the packet will be denied depending on the ordering of the groups on the port. Therefore, I'd argue that the software is not working as intended.

The ability to assign multiple groups to a port is a desired feature. It would allow administrators to apply a default top-level group to projects, and allow users to add their own groups below it to extend access to their project. However, the current behavior prevents this because the groups are re-ordered unintentionally.

Adding ordering/positioning to attached groups seems to be the best path forward.