Skip to content

Conversation

@lwander
Copy link
Contributor

@lwander lwander commented Jul 24, 2017

A specific content type needs to be specified for create requests; the kubernetes swagger.json lists consumes [ "*/*" ] for most resource create requests, which can't be set as a content-type header directly.

Since all requests are serialized into JSON this seems appropriate.

@brendandburns @mbohlool PTAL

* or matches any, JSON will be used.
*/
public String selectHeaderContentType(String[] contentTypes) {
if (contentTypes.length == 0) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think we can do this, we'll need to make this change in the upstream swagger-codegen and I don't think we can land it there.

The right thing to do is to fix the Kubernetes swagger to not have this.

Copy link
Contributor

@mbohlool mbohlool Jul 25, 2017

Choose a reason for hiding this comment

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

... and I don't think we can land it there.

We did this for python client. swagger-api/swagger-codegen#4152
I think it is a reasonable thing to do because swagger client prefers json and when content type is */*, that includes json.

The right thing to do is to fix the Kubernetes swagger to not have this.

I also agree with this regardless of swagger-codegen fix.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My read of the Kubernetes swagger was that it was declaring that it, as a server, accepts anything (*/*). If this is true, it's up to the client to decide what it wants to send, and requires either swagger-codegen to be smarter about assigning content types or us as consumers of the generated code to be explicit in what we are sending. But of course, if Kubernetes only accepts json & yaml for example then the right fix is in the Kubernetes swagger.

An alternative to modifying ApiClient in place is to subclass it and override this method to avoid having our changes overwritten by running codegen. Although - when I tested this against the autoupdate script it left my changes in place, so I'm not sure what's going on there.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, let's due the PR in upstream swagger-codegen. They've been great about quick turnaround in the past. Once that is merged, I'm happy to merge this PR.

Copy link
Contributor

Choose a reason for hiding this comment

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

(and let me know if you need help with the PR, I've done a bunch of them myself)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good.

And thanks - I've done one myself now too so this shouldn't be too bad.

@lwander
Copy link
Contributor Author

lwander commented Jul 25, 2017

Closing for: #58

@lwander lwander closed this Jul 25, 2017
@lwander lwander deleted the fix-create-resource branch July 25, 2017 20:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants