-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Add option to add authentication to Jaeger and custom tags #13728
Conversation
started the job as gitpod-build-aledbf-jaeger.3 because the annotations in the pull request description changed |
/werft run with-clean-slate-deployment 👍 started the job as gitpod-build-aledbf-jaeger.6 |
/werft run with-preview with-clean-slate-deployment 👍 started the job as gitpod-build-aledbf-jaeger.7 |
/werft run with-clean-slate-deployment with-preview 👍 started the job as gitpod-build-aledbf-jaeger.9 |
if context.Config.Observability.Tracing.SecretName != nil { | ||
res = append(res, corev1.EnvVar{ | ||
Name: "JAEGER_USER", | ||
ValueFrom: &corev1.EnvVarSource{SecretKeyRef: &corev1.SecretKeySelector{ | ||
LocalObjectReference: corev1.LocalObjectReference{Name: *context.Config.Observability.Tracing.SecretName}, | ||
Key: "JAEGER_USER", | ||
}}, | ||
}) | ||
|
||
res = append(res, corev1.EnvVar{ | ||
Name: "JAEGER_PASSWORD", | ||
ValueFrom: &corev1.EnvVarSource{SecretKeyRef: &corev1.SecretKeySelector{ | ||
LocalObjectReference: corev1.LocalObjectReference{Name: *context.Config.Observability.Tracing.SecretName}, | ||
Key: "JAEGER_PASSWORD", | ||
}}, | ||
}) | ||
} |
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.
Why do we expose these as ENV variables? In general, mounting the secret as a volume is preferred for credentials and here we could do that if the SecretName is specified.
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.
That's how the library is configured.
cfg, err := jaegercfg.FromEnv() |
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.
We could construct that manually, from the information we mount - https://pkg.go.dev/github.com/uber/jaeger-client-go/config#Configuration
I'll raise an issue as a follow-up (which will likely never get done) as I don't want to block your change but we do abuse env variables a fair bit.
@@ -112,7 +112,7 @@ func DefaultEnv(cfg *config.Config) []corev1.EnvVar { | |||
) | |||
} | |||
|
|||
func WorkspaceTracingEnv(context *RenderContext) (res []corev1.EnvVar) { | |||
func WorkspaceTracingEnv(context *RenderContext, component string) (res []corev1.EnvVar) { |
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.
Do we need this indirection here if we're actually keeping them the same? Could we instead consolidate on func TracingEnv(...)
. If the need for these to actually be different arises, we can refactor.
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.
I don't know the reason.
ping @mrsimonemms
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.
Nothing to do with me I'm afraid. This was added by @andrew-farries around 5 months ago - 1119e55
@aledbf updated release notes as it didn't seem to be useful for the end Gitpod user. Let me know if this change is wrong. |
@aledbf: Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it. 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. |
@atduarte it depends on who is the "Gitpod user". If you are installing Gitpod, this is an important thing to know. |
@aledbf I understand the confusion. Release Notes are automatically added to the gitpod.io changelog (October's, September's) and therefore should focus only on the end-user (i.e. the developer persona). Some additional internal information can be found here: 1, 2. |
You are correct that we should treat the installer as a first-class citizen for the Self-Hosted context, however see below for reasons on why we should omit for now 👇
Currently, yes. That's also my understanding. @lucasvaltl can confirm, but I believe Self-Hosted are cherry-picking PR's and manually curating the release notes right now (see past example) and omitting Release Notes. No defined heuristic exists (that I'm aware of) to distinguish Self-Hosted / installer facing pull requests from SaaS or developer persona pull requests... that heuristic needs creating and agree'ing on, then we can easily distinguish between the two. CC: @filiptronicek |
Description
Related Issue(s)
Fixes #13381
Fixes #13385
How to test
and verify the env variables
JAEGER_USER
andJAEGER_PASSWORD
are configured.Release Notes
Werft options:
If enabled this will build
install/preview
Valid options are
all
,workspace
,webapp
,ide