-
Notifications
You must be signed in to change notification settings - Fork 682
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
Allow setting custom_tags for traces #4181
Allow setting custom_tags for traces #4181
Conversation
8543df2
to
c89902e
Compare
I have experimented with a couple of alternatives, and I am not sure which one if preferred. Option 1: Custom conversionsWhen storing from v3alpha1 into v2, convert DeprecatedTagHeaders into custom tags and append to CustomTags, When reading back from v2 to v3alpha1, convert TagHeaders into custom tags and append to v3CustomTags, Whatever you put in v3alpha1 goes cleanly into v2, but when converting it back again to v3alpha1 the objectdoes not have the exact same data. The v3alpha1 DeprecatedTagHeaders will always be empty. Option 2: No need for custom conversionsv2 TagHeaders <-> v3alpha1 DeprecatedTagHeaders Whatever you put in v3alpha1 goes cleanly into v2, and when converting it back again to v3alpha1 the object has the exact same data. The TestConvert fn in conversion_test.go assumes this behavior. |
Hey @psalaberria002! As I understand it:
That implies to me that the best answer here is:
How does that sound? |
e8da8d9
to
3a8684f
Compare
Makes sense. I have tried to follow that approach in the last commit. It would be nice to have CI for this PR :) |
3a8684f
to
97ee0c7
Compare
5835a4b
to
a8a49ae
Compare
a8a49ae
to
c42c9d9
Compare
@psalaberria002 - Thanks for being patient on this. With the recent release master has diverged quite a bit. Can you please rebase this back on master and push it. I will then get CI running on it. Note: it's probably good to run |
Already pulled from master, cherry picked my change, and force pushed. |
c42c9d9
to
af92682
Compare
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.
@psalaberria002 - it looks pretty good and seems to line up with the discussion between Flynn and you.
I have a few open items I want to check with the team to make sure I understand historical context and a left a few nits as well.
We may want a pytest/kat test for when both req_hdrs
and custom_tags
but let me find out more on whether that is necessary.
60edbbb
to
8dbe260
Compare
cbd0e76
to
755ce83
Compare
@psalaberria002 - lets get this rebased on master and update the release notes so that it will land on the upcoming Again thanks for the patience on this. |
755ce83
to
2ee0cad
Compare
Rebased. I am not able to run tests locally. It would be great if you could run this in CI. |
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.
A couple final last nits and then I'm all good. If you could make those changes and then I will pull them in, verify CI is still green and we can get this merged!
Thanks for all the help and putting up with the painful process!
StatsName string `json:"stats_name,omitempty"` | ||
Service string `json:"service,omitempty"` | ||
Sampling *TraceSampling `json:"sampling,omitempty"` | ||
// tag_headers is deprecated. Use custom_tags instead. |
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.
It looks kubebuilder has no notion of deprecation validation so let's at least take advantage of Golangs doc comments for deprecated.
https://stackoverflow.com/questions/7849663/how-do-you-mark-code-as-deprecated-in-go
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.
This one is a little bit tricky. The comments endup in the CRD specs. The Deprecated convention in Go is for the struct fields, not the json fields. I am not sure if this is worth it. If so, can you write down here the expected comment string?
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.
Correct, the reason I suggested the Go Doc comment is that these objects can be used in the future where we have a transformation engine that is written in Go. This way if objects are being instantiated via Go code the IDE is going to yell you.
However, I was reading through the docs this morning and it looks like there is a deprecated special marker. It says on-type so it might not work on fields but ideally it can be applied to a field too.
https://book.kubebuilder.io/reference/markers/crd.html
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.
+kubebuilder:deprecatedversion
doesn't seem to do anything on fields. I am gonna add the Go deprecation comment and use the json fields in the description since those are visible both in the CRD schema and the Go code.
b4359bb
to
748eec0
Compare
It allows setting trace tags based on literal values, environment variables, or request headers. Based on https://www.envoyproxy.io/docs/envoy/latest/api-v3/type/tracing/v3/custom_tag.proto#custom-tag Signed-off-by: Paul Salaberria <psalaberria002@gmail.com>
Signed-off-by: Paul Salaberria <psalaberria002@gmail.com>
Signed-off-by: Paul Salaberria <psalaberria002@gmail.com>
Signed-off-by: Paul Salaberria <psalaberria002@gmail.com>
Signed-off-by: Paul Salaberria <psalaberria002@gmail.com>
Signed-off-by: Paul Salaberria <psalaberria002@gmail.com>
Signed-off-by: Paul Salaberria <psalaberria002@gmail.com>
@psalaberria002 - Landed this in #4268 per our discussion in slack. Closing this one out. |
It allows setting trace tags based on literal values, environment variables, or request headers.
Based on https://www.envoyproxy.io/docs/envoy/latest/api-v3/type/tracing/v3/custom_tag.proto#custom-tag
tag_headers
should be deprecated in favor ofcustom_tags
. I haven't worked with CRDs and field deprecations. What's the procedure?When it comes to updating the documentation, where is that handled? I cannot find any reference to
TracingService
inside the docs folder.