Skip to content
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

Treat JSON values as string for translation #28629

Merged
merged 1 commit into from
Nov 6, 2020

Conversation

ostromart
Copy link
Contributor

Fixes #24318.

@ostromart ostromart requested a review from a team as a code owner November 5, 2020 20:52
@google-cla google-cla bot added the cla: yes Set by the Google CLA bot to indicate the author of a PR has signed the Google CLA. label Nov 5, 2020
@istio-testing istio-testing added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label Nov 5, 2020
Copy link
Member

@howardjohn howardjohn left a comment

Choose a reason for hiding this comment

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

Can you remind me why we actually treat string as yaml? I vaguely recall this but forgot. It feels "wrong" but hard to say without know why we do it

@ostromart ostromart added cherrypick/release-1.8 release-notes-none Indicates a PR that does not require release notes. labels Nov 6, 2020
@ostromart
Copy link
Contributor Author

/retest

@istio-testing
Copy link
Collaborator

In response to a cherrypick label: new pull request created: #28660

@ostromart
Copy link
Contributor Author

/cherrypick release-1.7

@istio-testing
Copy link
Collaborator

@ostromart: new pull request created: #28665

In response to this:

/cherrypick release-1.7

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.

@ostromart
Copy link
Contributor Author

to support patching a path with an object rather than a scalar. there may be some other way to do this but fundamentally the problem is that yaml expects a scalar for this:

key: value

and there's no way that i know of that would let you also support this:

key:
  key2: value

other than passing a scalar string:

key: |
  key2: value

@howardjohn
Copy link
Member

@ostromart makes sense. I have no clue what this would look like in practice, but in theory you could have it be a custom type like IntOrStr in k8s, where we determine the type during unmarhal. Probably a HUGE pain to do though, go is not good that this stuff

@ostromart
Copy link
Contributor Author

the difficulty is that objects in yaml don't unmarshal into an interface{} type - you need something like map[string]interface{}, in which case then scalars won't unmarshal. we'd probably have to create both versions of IstioOperatorSpec and then see if either one would unmarshal or do some crazy stuff with reflect.

@howardjohn
Copy link
Member

Can we not make a custom type like StringOrMap following intOrStr? Not sure how that works with our "proto first" apis though. yaml/proto suck 🙂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes Set by the Google CLA bot to indicate the author of a PR has signed the Google CLA. release-notes-none Indicates a PR that does not require release notes. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

meshConfig.accessLogFormat doesn't work
4 participants