Draft
Conversation
…1. Allow make generate-fast to work with it. Signed-off-by: Flynn <emissary@flynn.kodachi.com>
kflynn
force-pushed
the
flynn/add-v4alpha1
branch
from
4e4efe1 to
dc6ddc6
Compare
Turns out that the Go ecosystem doesn't currently offer control over the tag used when serializing or deserializing JSON or YAML. This is pretty appalling. We need control over the tag, and the most sane way I've found to support that is _copying all of encoding/json and sigs.k8s.io/yaml into our tree_ and modifying them. Ugh. Bad ecosystem! Signed-off-by: Flynn <emissary@flynn.kodachi.com>
…e json tag (and, also, it doesn't rely on internal imports) Signed-off-by: Flynn <emissary@flynn.kodachi.com>
… (as needed). Signed-off-by: Flynn <emissary@flynn.kodachi.com>
…t to migrate all the v3alpha1 testdata for emissary-ingress.dev/v4alpha1 over to proper v4 CRDs. Signed-off-by: Flynn <emissary@flynn.kodachi.com>
kflynn
force-pushed
the
flynn/add-v4alpha1
branch
from
dc6ddc6 to
3e925af
Compare
Signed-off-by: Flynn <emissary@flynn.kodachi.com>
…ions don't! Really, standard library authors? Really?? Signed-off-by: Flynn <emissary@flynn.kodachi.com>
Signed-off-by: Flynn <emissary@flynn.kodachi.com>
Signed-off-by: Flynn <emissary@flynn.kodachi.com>
…world. This is the point where we _start_ to have some functionality working. The FakeCollision test passes after this change(!!). Signed-off-by: Flynn <emissary@flynn.kodachi.com>
Signed-off-by: Flynn <emissary@flynn.kodachi.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This has been... ugly.
We're starting from the point of view that the v4alpha1 CRDs should be camelCase internally, but that we'll need to still use snake_case when talking to Python (purely as a practical matter of paranoia). Managing that... wow. The Go ecosystem, you see, does not give you control over the tag used when serializing or deserializing JSON or YAML.
The Right Way to manage this may be a PR into
encoding/jsonandsigs.k8s.io/yaml. The short-term way? I've copied those into Emissary's codebase and hacked them. 😛The end result is:
encoding/jsonuses thejsontag (for camelCase v4alpha1 nativeness)github.com/emissary-ingress/emissary/v3/pkg/jsonuses thev3tag but falls back to thejsontag (for snake_case v3alpha1 madness)sigs.k8s.io/yamluses theyamlandjsontags (for camelCase v4alpha1 nativeness)github.com/emissary-ingress/emissary/v3/pkg/yamluses thev3tag but falls back to theyamlandjsontags (for snake_case v3alpha1 madness)and
cmd/migratorhas the beginnings of a conversion tool. I say "beginnings" because it currently only does snake_case YAML to camelCase YAML but it's a start... and I used it to convert the testdata manifests for the v4alpha1 CRDs.Signed-off-by: Flynn emissary@flynn.kodachi.com