Comment 6 for bug 1518087

As I mentioned on comment #4, I am happy to revise the decision, but a decision will have to be made at some point.

I'll go over your detailed explanation as why you think this is justified, but from a quick run through, I don't see why pre-deployment validation wouldn't suffice to address any use case you mentioned here (from the least to the most complex). In the end, each MD should know where and how to enforce security groups, and I don't see how the rejection of this proposal prevents that from happening. On the other end, I personally wouldn't want to promote tight coupling between MD's, because that defeats the whole point of modularity.

You said, and I quote you:

"letting ML2's port binding reject the inappropriate potential bindings (combinations of MDs) and move on to find another binding that will work"

This may be susceptible to race conditions, and different configuration ordering can lead to different binding results leading to something that may be difficult to troubleshoot. MD should independently know what they are supposed to do security-wise (amongst other things), and so long as there's a fixed contract (provided by the Neutron security group's API), I am unable to grasp how this proposal address any of your concerns.

I may not have a complete understanding of ML2, and it's fair to say that you are the most knowledgeable person of ML2 on the planet. That said, making it more complicated definitely doesn't help my job in understanding/maintaining it any easier, and since you no longer involved as you're used to, I find very hard to make an executive decision that promotes further complexity.