Conformance: Set Accepted Condition Type on Gateway Status

[kate-osborn]

Set Accepted Condition Type on Gateway Status.

From the spec:

Accepted is true when the controller managing the Gateway is syntactically and semantically valid enough to produce some configuration in the underlying data plane.

Accepted does NOT indicate whether the configuration has been propagated to the data plane.

The table below outlines the spec's reasons for the Accepted Condition Type, their values, and details on when to use them:

Reason	Value	Details
Accepted	True	Gateway is syntactically and semantically valid enough to produce some configuration.
ListenersNotValid	True	When one or more listeners have an invalid or unsupported configuration. Set to true when some configuration can still be generated for the Gateway.
ListenersNotValid	False	When one or more listeners have an invalid or unsupported configuration. Set to false when NO configuration can be generated for the Gateway.
Invalid	False	Use when the Gateway is syntactically or semantically invalid.
UnsupportedAddress	False	The requested address in the Gateway is not supported.
Pending	Unknown	Used when no controller has reconciled the Gateway. NKG does not need to set this.

We should prefer to use these reasons with the Accepted Condition Type, but we are not strictly limited to these reasons. We can define our own reason if the need arises.

Questions:

• Since we don't support the GatewayAddress field on Gateway, should we use the UnsupportedAddress condition when a user specifies it? No, use UnsupportedValue reason.
• Do we have the appropriate validation in place for Gateway resources to set the Accepted Condition Type? Validation is done for listeners. Some work is required to determine whether a Gateway is valid, partially valid, or invalid.
• NKG only supports one Gateway. If multiple Gateways are defined for the NKG GatewayClass, we select one Gateway and ignore the others. What status should we write to the ignored Gateways? Accepted/false/reason?? I think we need our own reason for this case. Currently, we set Ready/False/GetawayReasonGatewayConflict. Instead, set to Accepted/False/GetawayReasonGatewayConflict and also fix type Getaway -> Gateway

Acceptance Criteria:

• Implement Accepted condition type according to the description above
• Add unit tests
• Update gateway API compatibility doc. Make sure to callout the GatewayReasonGatewayConflict reason and explain that we only support one Gateway

[kate-osborn]

https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1beta1.GatewayStatus I will look into this and refine