when LB is blocking a connection. should we add all other rules to the explainability

[haim-kermany]

Karen words:
n the case where the source is a LB and the destination is not a pool member I would print a message along the lines of

The load balancer will not connect to this endpoint since it is not a pool member

and nothing else (drop the explanation about SGs and nACLs). I doubt users are interested in an analysis of the nACLs and SGs in this case.

Either way, if you choose to elaborate SGs and nACLs on the way, do not use the phrasing "blocks connection" because the LB is not a firewall and cannot actually block connectivity.

[haim-kermany]

@ShiriMoran @kyorav @adisos @zivnevo

[zivnevo]

This is really a corner case. I don't expect users to hit it often.
If they do, it's OK to omit all other rules and it's OK to include them. Whatever makes the code simpler.
Just make sure that the "not a pool member" explanation comes first.

[haim-kermany]

is it a corner case?

[ShiriMoran]

In explainability we provide all information which is relevant to the path; better stay consistent with this rule. Both for the simplicity of code and consistency of answers.
The fact the connection is blocked ("can not be initiated") with the reason for it ("LoadBalancer rule") is provided in the "header". The user may decide to skip further explanation if these are not interesting.