godeps: update go-restful

[mikedanese]

To pickup emicklei/go-restful#311

@kubernetes/sig-api-machinery

---

This change is

[caesarxuchao]

cc @mbohlool

[caesarxuchao]

LGTM. @nikhiljindal @mbohlool do you have comments?

[lavalamp]

I'm a bit confused as to whether this is a desirable change or not. If we expect base64 data, reporting that as "string" in swagger is probably unhelpful? @mbohlool to decide :)

[mikedanese]

@lavalamp this is part of the golang encoding/json standard. Validation is broken without this.

[mikedanese]

E.g. we can't create csrs from kubectl without --validate=false

[mikedanese]

The field doc should state that the data is base 64 encoded as is the case for CSR Request field. https://github.com/kubernetes/kubernetes/blob/master/pkg/apis/certificates/v1alpha1/types.go#L43

Currently the swagger spec says array of integer for this which is completely wrong. This is a strict improvement.

[nikhiljindal]

I agree that string is an improvement over int array :)

@mikedanese You will have to run hack/update-api-reference-docs.sh to update api reference docs based on the swagger spec update.

[mbohlool]

What if somebody really means byte array? I guess array of integer could be wrong there too, but it is closer, right?
Another solution to this is to define a "type Something []byte" and customize the swagger type for it. You can follow the model of SchemaFormatHandler for Types.

[mikedanese]

@mbohlool In golang the json represntation of a []byte is a base64 encoded string. Both encoding/json and ugorji respect this.

From https://godoc.org/encoding/json

Array and slice values encode as JSON arrays, except that []byte encodes as a base64-encoded string, and a nil slice encodes as the null JSON value.

It's not optional. To encode a byte array as an array of ints, you would have to write your own json encoder.

[lavalamp]

That's not the part I'm waffling over-- it's the conflation between
"string" and "base64 encoded data stored in a string", which are not the
same types at all.

On Thu, Aug 18, 2016 at 2:27 PM, Mike Danese notifications@github.com
wrote:

@mbohlool https://github.com/mbohlool In golang the json represntation
of a []byte is a base64 encoded string. Both encoding/json and ugorji
respect this.

From https://godoc.org/encoding/json

Array and slice values encode as JSON arrays, except that []byte encodes
as a base64-encoded string, and a nil slice encodes as the null JSON value.

It's not optional. To encode a byte array as an array of ints, you would
have to write your own json deserializer.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#30914 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnglt1m-KJdOQQsnn1nl7KfVskNl1Vwks5qhM5WgaJpZM4Jnx5X
.

[mbohlool]

related to this: OAI/OpenAPI-Specification#50

[mbohlool]

in open-api/swagger 2.0, this should be represented as type="string", format="byte" to distinct two cases. I guess some swagger 1.2 tools will understand that too.

[k8s-bot]

GCE e2e build/test passed for commit d086e98.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

[mikedanese]

That's not the part I'm waffling over-- it's the conflation between
"string" and "base64 encoded data stored in a string", which are not the
same types at all.

I'm all for making this type doc more explicit but swagger validation is expecting an int array right now, which is not even possible to pass in for a []byte since go won't deserialize an int array to a []byte field. Swagger spec generator and golang stdlib json spec have a mismatch between the mapping of go types to json types. This fixes that and fixes a bug that breaks the kubectl experience for an alpha feature we want to release in 1.4 kubernetes/enhancements#43 .

Do you agree that "int array" is worse then "string" in swagger spec to represent "string that is base64 encoded bytes"? Can we improve this doc incrementally so as to fix a bug for the v1.4 release?

[lavalamp]

Yes I agree this is at least an improvement.

/lgtm

On Thu, Aug 18, 2016 at 3:17 PM, Mike Danese notifications@github.com
wrote:

That's not the part I'm waffling over-- it's the conflation between
"string" and "base64 encoded data stored in a string", which are not the
same types at all.

I'm all for making this type doc more explicit but swagger validation is
expecting an int array right now, which is not even possible to pass in for
a []byte since go won't deserialize an int array to a []byte field. Swagger
spec generator and golang stdlib json spec have a mismatch between the
mapping of go types to json types. This fixes that and fixes a bug that
breaks the kubectl experience for an alpha feature we want to release in
1.4 kubernetes/enhancements#43
kubernetes/enhancements#43 .

Do you agree that "int array" is worse then "string" in swagger spec to
represent "string that is base64 encoded bytes"? Can we improve this doc
incrementally so as to fix a bug for the v1.4 release?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#30914 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAngljiQJDOBYNmFKxEiEd5yfF13UkLVks5qhNoCgaJpZM4Jnx5X
.

[mbohlool]

I also agree that this is an improvement, I think we should set the type to "byte" too and definitely fix this for swagger 2.0 generation, if it is already an issue. but this PR looks good to me.

[mikedanese]

Thanks for review!

[mbohlool]

You are welcome. I also meant to set the format to "byte" not the type. The type should stay as string. Thanks for the fix.

[k8s-github-robot]

This PR is not for the master branch but does not have the cherrypick-approved label. Adding the do-not-merge label.

[mikedanese]

Why is @k8s-merge-robot saying this?

[k8s-github-robot]

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

[k8s-bot]

GCE e2e build/test passed for commit d086e98.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

[k8s-github-robot]

Automatic merge from submit-queue