Expand output for `gwctl describe httproutes`

[gauravkghildiyal]

Refer https://gateway-api.sigs.k8s.io/geps/gep-2722/ and https://github.com/kubernetes-sigs/gateway-api/issues/2761 for details

[gauravkghildiyal]

/area gwctl @tdn21 -- Sorry for the delay. Please "/assign" this to yourself if you would be willing to contribute.

FYI: We may want to wait for https://github.com/kubernetes-sigs/gateway-api/pull/2999 to merge

[tdn21]

No worries @gauravkghildiyal and thank you for creating the issue. /assign

[gauravkghildiyal]

Hey @tdn21, did you get a chance to look into this?

[gauravkghildiyal]

Hey @tdn21, did you get a chance to look into this?

[tdn21]

Hello @gauravkghildiyal, apologies for the delay. I've checked the expected output and identified the required changes. I'll most likely submit a draft PR today or tomorrow. (draft because i'd like to get some initial feedback on inherited policies logic before opening it for review.)

[tdn21]

Hi @gauravkghildiyal, I have a couple of questions about inherited policies. Please bear with me as some of them might seem basic due to my limited understanding of policies.

1. Looking at the demo output from GEP-2722, we're displaying the target name field. For namespaced objects like the gateway, should we include a <namespace>/ prefix in the name?

   InheritedPolicies:
     TYPE                   NAME                                 TARGET KIND   TARGET NAME
     ----                   ----                                 -----------   -----------
     TimeoutPolicy.foo.com  demo-timeout-policy-on-gatewayclass  GatewayClass  abc-gatewayclass
     RetryOnPolicy.baz.com  demo-retry-policy-1                  Gateway       abc-gateway

2. Does the ordering or grouping of inherited policies matter? If so, what's the recommended way to order or group these policies? (We might consider grouping these policies per gateway or perhaps we can consider grouping by hierarchy with top to down ordering of these groups)

3. Could you please clarify the significance of the inherited boolean field in the Policy struct (ref)? Does it indicate that if a policy's value is false, then that specific policy cannot be inherited? Or is it simply to indicate that certain policies can only be inherited and not directly applied, with all direct policies inherited by relevant objects at lower hierarchy levels?

[gauravkghildiyal]

Those are all valid and good questions, @tdn21. Thanks for requesting clarification.

1. Yes definitely, let's include the prefix for namespaced resources. I've been meaning to do it in a couple of other places as well, and it's good to start with this.

2. For the time being, let's simply sort them by their TYPE and NamespacedName. The actual grouping/ordering/hierarchy is supposed to be represented by the EffectivePolicy so let's avoid an additional level of complexity here.

3. Yes exactly this: "Does it indicate that if a policy's value is false, then that specific policy cannot be inherited" See below for some futher details.

---

Essentially:

1. You'll start with a filtering function that takes in a map[policyID]*PolicyNode and filters this to a map of policies which can be inherited (i.e. have the inherited field set to true).
2. Inherited policy for Gateway = inherited(policies for GatewayClass) + inherited(policies for Gateway Namespace)
3. Inherited policy for HTTPRoute = inherited(policies for Gateway, calculated in previous step) + inherited(policies for HTTPRoute Namespace)
4. Inherited policy for Backend = inherited(policies for HTTPRoutes, calculated in previous step) + inherited(policies for Backend Namespace)

Essentially, the inherited policy for a resource is effectively the aggregation of all policies that are inheritable by resources in it's hierarchy.

You do not need to include these changes in your PR, but just so you don't get confused, we'll later on re-use the same "filtering for inherited policies" function within the EffectivePolicies calculation as well. So essentially, EffectivePolicies will be the merging of all inherited policies.