-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
tracing: new jaeger independent helm chart #5240
Conversation
This PR moves tracing into a jaeger chart with no proxy injection templates. We still keep the dependency on partials, as we could use common templates like resources, etc from there. Signed-off-by: Tarun Pothulapati <[email protected]>
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.
Thanks @Pothulapati, this is a great start! I think we'll want to move everything, including the chart, into the top level jaeger
directory.
I noticed that you left the original tracing chart alone in this PR which I think is the right approach. There will need to be follow-up work to switch the main control plane to send traces to this collector instead and then to eventually delete the old tracing addon chart.
cc9ad0e
to
dba1ae7
Compare
Adds a new jaeger high level folder which contains the cli code. This contains its own `Values` based on `jaeger/values.yaml`. It re-uses a lot of code from cli install, and follows the code format and logic. A lot of code is copy pasted, and could have a refactor commit, to make it re-usable. Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Also, added jaeger deps to the gitignore so that we are not storing dependencies in the repo Signed-off-by: Tarun Pothulapati <[email protected]>
Adds a new `Fs` field in `Chart` struct to represne the file system which should be used for the rendering of files. This is used with jaeger and other extensions to be able to render charts from different top level directories. Signed-off-by: Tarun Pothulapati <[email protected]>
dba1ae7
to
7917ed8
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.
Looking good 👍
FYI, I'll be implementing the webhook on top of this branch.
Do you mind completing the entries in bin/helm-build
for this new chart?
RootCmd.PersistentFlags().StringVarP(&controlPlaneNamespace, "linkerd-namespace", "L", defaultLinkerdNamespace, "Namespace in which Linkerd is installed [$LINKERD_NAMESPACE]") | ||
RootCmd.PersistentFlags().StringVar(&kubeconfigPath, "kubeconfig", "", "Path to the kubeconfig file to use for CLI requests") | ||
RootCmd.PersistentFlags().StringVar(&kubeContext, "context", "", "Name of the kubeconfig context to use") | ||
RootCmd.PersistentFlags().StringVar(&impersonate, "as", "", "Username to impersonate for Kubernetes operations") | ||
RootCmd.PersistentFlags().StringArrayVar(&impersonateGroup, "as-group", []string{}, "Group to impersonate for Kubernetes operations") | ||
RootCmd.PersistentFlags().StringVar(&apiAddr, "api-addr", "", "Override kubeconfig and communicate directly with the control plane at host:port (mostly for testing)") |
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 didn't see controlPlaneNamespace
nor apiAddr
being used. Any plans on using them later on?
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.
Yeah, controlPlaneNamespace
is removed but other k8s related flags should be useful for the check stuff.
Signed-off-by: Tarun Pothulapati <[email protected]>
7917ed8
to
9a8676d
Compare
Signed-off-by: Tarun Pothulapati <[email protected]>
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.
Since this new chart is unused by the current CLI, merging this should be a safe thing to do. Let's prioritize getting the issues raised on this PR fixed up so that we can merge this to main before adding more functionality (such as validation, new flags, etc.). We can then work on that stuff in follow-up PRs.
pkg/charts/charts.go
Outdated
@@ -22,14 +23,16 @@ type Chart struct { | |||
Namespace string | |||
RawValues []byte | |||
Files []*chartutil.BufferedFile | |||
Fs http.FileSystem |
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 like Fs and Dir are always combined. Any reason we can't just turn the Dir
field into a http.FileSystem
so that we don't need both? (I think os.File
would probably be better, but that's a larger change)
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 feels better, as not all code paths have to configure the filesystem field, they just use static.Templates
which is the default i.e /charts
and set the Dir
based on their chart name.
If we combine them, Every Chart
creator code-path will have to configure the http.FileSystem
field to their chart directory. WDYT?
metadata: | ||
name: collector | ||
namespace: {{.Values.namespace}} | ||
labels: |
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.
what is the purpose of these labels?
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.
These are not helpful for serviceAccounts
, but I kept them as we had them for services and deployments.
Removing them.
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
d715e4e
to
a004d1f
Compare
This branch removes dir field and makes users only specify the full path in `Fs` field. Helper functions are added to make this easy. Changes are also made in charts generation code to remove the passage of `Charts.yaml` for dependency charts i.e partials, etc as it confuses the generation. Only the top level charts will pass the `Chart.yaml` and for every other dep chart they only pass the templated files for rendering. Signed-off-by: Tarun Pothulapati <[email protected]>
a004d1f
to
3631351
Compare
pkg/charts/charts.go
Outdated
filename = filename[7:] | ||
} | ||
file, err := static.Templates.Open(filename) | ||
file, err := fs.Open(filename) |
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.
Here you're reading directly from fs
. When doing linkerd install
, this ends up being static.WithDefaultChart(helmDefaultChartDir)
which points directly to the "real" file system.
Before, we had static.Templates.Open(filename)
which hits the "real" file system when !prod
and the VFS when prod
. So this is why it's failing the integration test (trying to hit the real FS instead of the VFS).
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.
Yep, That makes sense, As static.Templates
is replaced by the logic to read from a VFS with code generation which our helper code is not doing similarly.
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.
Lets push the CLI and chart rendering stuff out of this PR so that we can merge the chart itself.
Then we'll need to open a new PR for the chart rendering changes. I didn't know about the VFS stuff we do here. I think the jaeger CLI package will need a function similar to the main CLI's static.Templates
which returns a FileSystem which may be either a VFS of it charts directory or may point to the real FS.
@adleong I am reverting the last commit, which involved the merging of I was trying to create a separate VFS generation specifically for For Now, I will move |
This reverts commit 3631351. Signed-off-by: Tarun Pothulapati <[email protected]>
Currently, Our VFS is tied to the higher level `chats` directory Because of the limitation of the VFSGen project, It does not seem possible to generate multiple variables in the same pkg. This can be solved in the future PRs Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
b9d0317
to
38d34f8
Compare
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
642545b
to
770c7ff
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.
LGTM 👍 , looking forward for the followup PRs 😉
I've branched off of this PR to create #5275 as a replacement which moves the jaeger charts out of the main charts directory as we discussed. It deletes the jaeger CLI for now. |
Created #5278 with only the CLI changes. Will close this once both of them are merged! |
Fixes #5230
This PR moves tracing into a jaeger chart with no proxy injection
templates. We still keep the dependency on partials, as we could use
common templates like resources, etc from there.
Signed-off-by: Tarun Pothulapati [email protected]