-
Notifications
You must be signed in to change notification settings - Fork 7.9k
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
Conversation
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.
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
/retest |
In response to a cherrypick label: new pull request created: #28660 |
/cherrypick release-1.7 |
@ostromart: new pull request created: #28665 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. |
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:
and there's no way that i know of that would let you also support this:
other than passing a scalar string:
|
@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 |
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. |
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 🙂 |
Fixes #24318.