Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expand output for gwctl describe httproutes #3037

Closed
Tracked by #2761
gauravkghildiyal opened this issue May 1, 2024 · 7 comments · Fixed by #3181
Closed
Tracked by #2761

Expand output for gwctl describe httproutes #3037

gauravkghildiyal opened this issue May 1, 2024 · 7 comments · Fixed by #3181
Assignees

Comments

@gauravkghildiyal
Copy link
Member

gauravkghildiyal commented May 1, 2024

Refer https://gateway-api.sigs.k8s.io/geps/gep-2722/ and #2761 for details

@gauravkghildiyal
Copy link
Member Author

/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 #2999 to merge

@tdn21
Copy link
Contributor

tdn21 commented May 1, 2024

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

@gauravkghildiyal
Copy link
Member Author

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

1 similar comment
@gauravkghildiyal
Copy link
Member Author

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

@tdn21
Copy link
Contributor

tdn21 commented May 8, 2024

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
Copy link
Contributor

tdn21 commented May 10, 2024

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
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants