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

Adding new AdmittedGateways field to Routes to improve kubectl output #587

Closed

Conversation

robscott
Copy link
Member

@robscott robscott commented Mar 18, 2021

What type of PR is this?
/kind cleanup
/kind api-change

What this PR does / why we need it:
This adds a new AdmittedGateways []string field in route status to list all Gateways that have admitted the route. This field is used in kubectl output to make it clearer which Gateways are bound to a given Route.

Which issue(s) this PR fixes:
Fixes #586

Does this PR introduce a user-facing change?:

Routes now include an admittedGateways field in status.

@k8s-ci-robot k8s-ci-robot added kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Mar 18, 2021
@k8s-ci-robot k8s-ci-robot requested review from hbagdi and thockin March 18, 2021 18:05
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: robscott

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 18, 2021
@robscott
Copy link
Member Author

/cc @jpeach @danehans

@k8s-ci-robot k8s-ci-robot requested review from danehans and jpeach March 18, 2021 18:06
// by any Gateway.
//
// +kubebuilder:validation:MaxItems=100
AdmittedGateways []string `json:"admittedGateways"`
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not tied to this name. I also considered AdmittingGateways, ConnectedGateways, or ActiveGateways if any of those seem better. Also open to other names.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the question is what are we trying to convey? If the status of the object was Admitted: false because there's some sort of error, should it still show in this list?

If that's the case then maybe admittedGateways isn't the right name (but was my first thought as well). =)

Possibly selectedGateways but that implies the opposite ordering (the route doesn't select the gateway).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think the most useful thing we can show here for kubectl is the Gateways that are actively using this Route. I was thinking that if a user expects a Gateway to be in the list and it isn't they can dig into the full yaml output/status.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that Admitted doesn't seem right, but I can't think of anything else that doesn't sound bad. InUseByGateways is probably accurate, but a bit of a mouthful.

@robscott robscott added this to the v0.3.0 milestone Mar 24, 2021
@@ -211,6 +211,19 @@ type RouteStatus struct {
//
// +kubebuilder:validation:MaxItems=100
Gateways []RouteGatewayStatus `json:"gateways"`

// AdmittedGateways is a list of Gateways that have admitted this route.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we make sure that there is one way language we talk about this relationship? Is it "admitted" or "bound" (both terms exist in the repo).

Ask: can we decide on one and change all references to be consistent?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like bound more :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we make sure that there is one way language we talk about this relationship?

+1, we currently use "Admitted" and should continue doing so IMO.

// namespace/name format. This field is primarily used to provide kubectl
// output.
//
// A maximum of 100 Gateways will be represented in this list. If this list
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we leave the #'s out of this comment? We should just say that this list may be truncated and also include an indicator for truncation:

AdmittedGatewaysTruncated bool

or something similar, maybe

AdmittedGatewaysCount int32

that people can see total even though it was truncated.

@@ -211,6 +211,19 @@ type RouteStatus struct {
//
// +kubebuilder:validation:MaxItems=100
Gateways []RouteGatewayStatus `json:"gateways"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should Gateways still exist? It seems redundant.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The big difference is that this list of Gateways includes all the conditions/status for the associated Gateways. In this PR I'm proposing adding a simpler []string for the purpose of populating kubectl output, but the full status/conditions would still be valuable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@robscott does kubectl provide a way to iterate through the gateway ref list and output gateways of "Admitted=True"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sadly not, that would simplify a lot of this. More examples of what I tried in #586 (comment). Unfortunately this is intentional behavior from upstream: https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiextensions-apiserver/pkg/registry/customresource/tableconvertor/tableconvertor.go#L111. There's been some discussion around improving that experience, but it has unfortunately not gone anywhere. kubernetes/kubectl#517 tracks the issue, but as I understand it, this is actually something that would need to change in apiserver, not kubectl. I think kubernetes/kubernetes#67079 would have fixed this but unfortunately went stale and was closed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if we were able to get a fix into Kubernetes 1.22, the kubectl experience would be quite poor for anyone on an older k8s version since the current implementation always returns the first element in the matching list.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this is the names of the gateways that are included in the Gateways array and have an Admitted status of true? If so, it's redundant but I can see your point here.

The doc should specify the semantic described here. I don't think that the intention is to invent new semantics for this field; we just want to make existing semantics consumable by kubectl. We should avoid the word "bound" since that's not a term of art in the API.

@k8s-ci-robot k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Apr 9, 2021
@k8s-ci-robot
Copy link
Contributor

@robscott: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@hbagdi
Copy link
Contributor

hbagdi commented Apr 12, 2021

@robscott Did we land on a decision on if we want to include this feature or hold it?

@robscott
Copy link
Member Author

@hbagdi Thanks for following up! This is on me to follow up with apimachinery to see what's possible/recommended for these kinds of things.

@robscott
Copy link
Member Author

robscott commented Apr 12, 2021

Sent this out to sig-api-machinery to see if they have any insight: https://groups.google.com/g/kubernetes-sig-api-machinery/c/GxXWe6T8DoM

@robscott robscott added the priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. label Apr 14, 2021
@robscott
Copy link
Member Author

I've created an upstream PR that should help with this. Of course that's probably only a realistic solution if we can also backport the fix to earlier k8s versions. For now I'm going to put a hold on this until there's more clarity upstream.

/hold

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Apr 16, 2021
@robscott
Copy link
Member Author

I think the correct approach is to try to solve this upstream, even though it will take more time. I'm closing this in favor of kubernetes/kubernetes#101205 for now. If I can't get momentum upstream I'll revisit making changes like this.

/close

@k8s-ci-robot
Copy link
Contributor

@robscott: Closed this PR.

In response to this:

I think the correct approach is to try to solve this upstream, even though it will take more time. I'm closing this in favor of kubernetes/kubernetes#101205 for now. If I can't get momentum upstream I'll revisit making changes like this.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@robscott robscott deleted the kubectl-gateway-status branch January 8, 2022 01:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
No open projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Add GATEWAYS field to kubectl get httproute output
9 participants