-
Notifications
You must be signed in to change notification settings - Fork 231
support Deprecated field #275
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
Conversation
fb079e1 to
6f34764
Compare
| } | ||
|
|
||
| func (o *openAPI) buildOperations(route common.Route, inPathCommonParamsMap map[interface{}]*spec3.Parameter) (*spec3.Operation, error) { | ||
| ret := &spec3.Operation{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for openapi v3, is it possible to set the deprecated field on the schema object as well as the operation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that'd be super sweet, especially if we automatically enable new mechanisms to help with deprecation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it should possible but it's not as straightforward and I thought it might be better to include in a follow up after some more discussion.
I'm still doing some investigations, but afaik we can't guarantee that a deprecated operation path would deprecate all the corresponding schemas associated with that path. An example of this is a delete on an alpha/beta resource that returns a meta.v1.Status. Is this a one-off exception or are there more examples of this?
For schema fields, there are cases where we deprecate a single schema field and not the entire schema. This is currently embedded in field descriptions, and it may be beneficial to include these programmatically as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
afaik we can't guarantee that a deprecated operation path would deprecate all the corresponding schemas associated with that path
IIUC, it shouldn't. Because an operation is deprecated doesn't mean that the type that it received is also deprecated.
Thanks for the perspective, I agree that it'd be nice to have deprecated either for entire types (v1beta1 type is deprecated) or for fields, but we would probably need new markers and what not, probably out of the scope of this project (but the types of things that are enabled by this project).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you look at how this deprecated operation setting is being driven from k/k, it's based on the entire primary struct for a set of operations being deprecated. Even if it's in another PR, having a way to plumb the fact that that struct is deprecated into openapi would be useful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, thanks for clarifying, I completely agree.
| // Deprecated marks a route as deprecated | ||
| Deprecated() bool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this be released as a breaking change? iirc, we were quite careful when adding this interface to not break backwards compatibility, suggest doing the same here. ref: #252 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did a quick scan of the k/k codebase, it looks like nothing is using the particular interface and all calls of the interface are from kube-openapi itself. The GetOperationIDAndTagsFromRoute in the PR linked has not yet been integrated into k/k yet.
So to answer your question, yes this will be a breaking change for current users of the API, but at the moment it seems like we have no users of the particular API (that we know of). I'm okay with taking the safe approach of just creating another interface, just want to gather some thoughts first.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your reply. I agree it isn't a huge breaking change and won't affect k/k, though will affect other projects using it (mine 😄), perhaps it's acceptable for this project to only support k/k.
Do you think it would be valuable to switch k/k to the interface, or rather wait until there's a push to get off go-restful?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for pointing that out, that's enough of a reason to create backwards compatibility and create a new interface. Do you have any preferences for the interface name?
I don't seem any harm in switching k/k to the interface, although that will be a decision up to the approvers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks very much for the backwards compat effort :) No real preference on name, perhaps DeprecatableRoute?
|
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
|
@Jefftree what's the plan here? |
6f34764 to
0c38d6d
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Jefftree The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@apelisse I think this provides valuable information to the OpenAPI and we should look to get it in once the pending comment is addressed. |
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
|
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
|
@k8s-triage-robot: Closed this PR. 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. |
go-restful is at version v2.9.5 in k/k already: https://github.com/kubernetes/kubernetes/blob/master/go.mod#L36
This PR supports publishing the deprecated field for an operation in both OpenAPI v2 and v3.
See kubernetes/kubernetes#107622 for how swagger.json changes with this update.
See kubernetes/kubernetes#107498 for more details on the issue.
/cc @apelisse @liggitt @sttts