-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Add GroupVersion tags to OpenAPI spec and remove all specs except main one #35388
Conversation
cc @bgrant0607 @thockin @lavalamp @kubernetes/sig-api-machinery Please look at this change as it is a design change. |
@@ -60,18 +60,15 @@ kube::log::status "Starting federation-apiserver" | |||
--insecure-port="${API_PORT}" \ | |||
--etcd-servers="http://${ETCD_HOST}:${ETCD_PORT}" \ | |||
--advertise-address="10.10.10.10" \ | |||
--cert-dir="${TMP_DIR}/certs" \ |
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.
@nikhiljindal this is the reason federation server did not start on my machine.
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.
ack, thx!
Jenkins unit/integration failed for commit 9d3a79346020a6174475502613152e65f44eba3a. Full PR test history. The magic incantation to run this job again is |
ed011bd
to
0b0a606
Compare
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.
+2,012 −48,660
is cool! Just curious, I thought we just merged the swagger into one file, why would the PR remove so many lines? Is it because there were many duplicate swagger definition before?
Also out of curiosity, when generating code, will the swagger paths with the same tags be generated as one file? What generating tool are we using?
@@ -72,10 +73,15 @@ func GetOperationID(servePath string, r *restful.Route) (string, error) { | |||
prefix = prefix + ToValidOperationID(strings.TrimSuffix(parts[1], ".k8s.io"), prefix != "") | |||
if len(parts) > 2 { | |||
prefix = prefix + ToValidOperationID(parts[2], prefix != "") | |||
tags = append(tags, fmt.Sprintf("%s_%s", ToValidOperationID(parts[2], false), ToValidOperationID(strings.TrimSuffix(parts[1], ".k8s.io"), false))) |
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.
Why version_group rather than group_version?
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.
That was Daniel's suggestion for spec filenames and I just followed naming pattern here. @nikhiljindal knows?
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 dont see a reason for version_group
. I think group_version
or group/version
or group.version
should be fine which is what we use at other places.
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.
Please don't use .
as the separator. Group might have .
in the name. (Though I remember you removed .k8s.io suffix)
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, I've used group_version.
I think we should always do GroupVersion because Group dominates Version. On Tue, Oct 25, 2016 at 6:01 AM, mbohlool notifications@github.com wrote:
|
Jenkins verification failed for commit a0435a6a965ffc7ebf1aa0550147ee6ef902364a. Full PR test history. The magic incantation to run this job again is |
LGTM once the group_version or version_group comment is resolved. Thx! |
@caesarxuchao We were generating swagger.json for all endpoints as well as a root one. This change will only keep root one and remove all those specs for endpoints, that why we have a lot of removed line. Generators (at least the one I've tried) generate one file (or class) for each tag. |
- Remove all end-point specs as they are not useful in light of GroupVersion tags in main spec
LGTM. Thanks. |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
Automatic merge from submit-queue |
Does this mean we no longer serve openapi specs per group? I thought we were trying to allow decentralizing discovery and schema info |
It is easy to convert the existing spec to any of the group spec (group them by tag). If we see a usecase for it, we can always bring it back (or write a simple tool to do the conversion) but we think it is easier to maintain this way. It is also possible (with little effort) to generate a client and pick the parts that you need (each tag will result in an API file. Before we had N spec and N API files, right now we have one spec and still N API files. If you only need core_v1, you can pick ApiCoreVi1.py (for python for example) the remove the rest. |
I'm more concerned about compatibility implications for clients that were fetching per group/version specs for validation (like kubectl). I couldn't tell if this was changing what was served by the API server. |
Oh, that is still swagger 1.2 that clients such as kubectl using and that is not changed. We are going to keep them for a while until we upgrade all clients to OpenAPI. |
Automatic merge from submit-queue Update verify-openapi-spec script to check for extra generated spec hack/verify-openapi-spec.sh only check for existing spec changes. If for some reason (here most probably I forgot to delete a file in api/openapi-spec folder in #35388 after a rebase) there is an old spec exists in the spec folder, it won't panic but it should. This resulted in an unused out of date v1.spec file in the api/openapi-spec folder that this PR also removes.
Tags are used as a grouping mechanism in OpenAPI. We generated one spec per GroupVersion before for this grouping but by adding those tags in this PR, those files have no use. We can always add them back if there were a use-case for them.
Release note:
Reference: #13414
This change is