conformance: gateway tests expecting wrong ListenerConditionReason

[mlavacca]

What happened:

In the conformance tests for the gateway there are two different tests [GatewaySecretInvalidReferenceGrant, GatewaySecretMissingReferenceGrant] that expect a listener to have the ReasonCondition as ListenerReasonInvalidCertificateRef. Both tests create a Gateway with a listener that refers to a secret in another namespace and there is no ReferenceGrant granting that reference.

For what concerns theListenerReasonInvalidCertificateRef, the godoc says that:

// This reason is used with the "ResolvedRefs" condition when the
// Listener has a TLS configuration with at least one TLS CertificateRef
// that is invalid or cannot be resolved.

while for what concerns theListenerReasonRefNotPermitted , the godoc says that:

// This reason is used with the "ResolvedRefs" condition when
// one of the Listener's Routes has a BackendRef to an object in
// another namespace, where the object in the other namespace does
// not have a ReferenceGrant explicitly allowing the reference.

Since the listener cannot reference the secret as there is no ReferenceGrant that allows that reference, the right reason to use for the ListenerCondition is ListenerReasonRefNotPermitted instead of ListenerReasonInvalidCertificateRef.

[mlavacca]

I'd be glad to work on a fix for this issue. If this is effectively a bug, I ask to be assigned to fix it.

[robscott]

I think you're right, thanks for catching this @mlavacca!

/assign @mlavacca

[skriss]

Just coming back to this and while I'm fine with using the RefNotPermitted reason for this scenario, I do think the API docs need some modifications to cover this more explicitly, since as pointed out above, currently the RefNotPermitted reason only talks about routes and backends (nothing to do with listeners and secrets). It might be worth also clarifying for InvalidCertificateRef, exactly what an "invalid" certificate ref is, and that it excludes this case of a disallowed cross-namespace reference.

[robscott]

Good call @skriss, filed #1362 to track that.