-
Notifications
You must be signed in to change notification settings - Fork 14.6k
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
Inconsistent use of the term "resource" #20074
Comments
That's also what I'd pick to put in documentation. In fact, it could even be a glossary entry: “In Kubernetes, a resource is…” |
/kind cleanup |
/language en |
/wg naming @kubernetes/wg-naming-leads I'm adding this to the backlog as lowest priority, as it is technically an naming/terminology issue? However it'll be at the bottom of the backlog. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
/sig architecture |
cc: @kubernetes/sig-architecture-leads |
/triage accepted |
The other big use of resources is to describe the things that limits and requests are limiting and / or requesting. We might not be able to avoid using the same English word to mean different things in different places, but we can call out when it might not be clear. |
In Chinese, a "resource" is always a "资源", difficult to differentiate too. |
Hi all, We've taken a look at this issue in the most recent WG naming meeting. We don't think there's an issue of language/inclusivity that needs to be addressed in this issue, so I'm going to remove the wg-naming tag. However, as a writer, there is definitely a developer style guide issue at play here, which would be useful to talk about in the next SIG Docs meeting |
/remove wg-naming |
And remember this is an issue not only for developers of the code, there is also the user-facing documentation. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
/remove-lifecycle stale |
/wg api-expression |
/remove-wg naming |
See #30092 (comment) for a specific suggestion. |
This issue has not been updated in over 1 year, and should be re-triaged. You can:
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/ /remove-triage accepted |
With the glossary entry PR merged, I think we can close this one. I'm closing this one as completed. |
@tengqm: Closing this issue. In response to this:
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. |
There's no entry for “resource” in https://kubernetes.io/docs/reference/glossary/?all=true /reopen |
@sftim: Reopened this issue. In response to this:
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. |
/triage accepted |
This issue has not been updated in over 1 year, and should be re-triaged. You can:
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/ /remove-triage accepted |
This is a Bug Report
Problem:
The term "resource" is used in inconsistent ways in the user-facing documentation and some prominent usages diverge from the common usage in the code. Sometimes "resource" is used like an object type or collection and sometimes it refers to an individual. This would not be so bad if the doc and code stuck to the usual web convention that a "resource" is anything that a URL locates, but the Kubernetes code and doc takes more particular stands --- but different ones in different places.
For example, https://kubernetes.io/docs/reference/using-api/api-concepts/#standard-api-terminology says
... and yet the introductory paragraph of that section contradicts itself in the parenthetic reference to "the
subjectaccessreviews
resource".https://kubernetes.io/docs/reference/using-api/api-overview/#enabling-specific-resources-in-the-extensions-v1beta1-group also uses the term "resource" in the sense of a type rather than an instance.
In the code the predominant usage of the word "resource" is to refer to the type rather than the instance. For example, see https://github.com/kubernetes/apimachinery/blob/master/pkg/runtime/schema/group_version.go .
Proposed Solution:
Either adopt a consistent usage throughout or explicitly give up.
Page to Update:
Most of them.
The text was updated successfully, but these errors were encountered: