Skip to content
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

Closed
wants to merge 20 commits into from
Closed

Conversation

Pothulapati
Copy link
Contributor

@Pothulapati Pothulapati commented Nov 17, 2020

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]

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]>
Copy link
Member

@adleong adleong left a 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.

charts/jaeger/Chart.yaml Outdated Show resolved Hide resolved
charts/jaeger/Chart.yaml Show resolved Hide resolved
charts/jaeger/templates/tracing-rbac.yaml Outdated Show resolved Hide resolved
charts/jaeger/templates/tracing-rbac.yaml Outdated Show resolved Hide resolved
charts/jaeger/templates/tracing-rbac.yaml Outdated Show resolved Hide resolved
jaeger/cmd/root.go Show resolved Hide resolved
jaeger/cmd/root.go Outdated Show resolved Hide resolved
jaeger/values/values.go Outdated Show resolved Hide resolved
jaeger/values/values.go Outdated Show resolved Hide resolved
jaeger/values/values.go Outdated Show resolved Hide resolved
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]>
Copy link
Member

@alpeb alpeb left a 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?

.gitignore Show resolved Hide resolved
jaeger/charts/jaeger/templates/tracing.yaml Outdated Show resolved Hide resolved
jaeger/charts/jaeger/templates/tracing.yaml Outdated Show resolved Hide resolved
Comment on lines +67 to +39
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)")
Copy link
Member

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?

Copy link
Contributor Author

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]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Copy link
Member

@adleong adleong left a 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.

@@ -22,14 +23,16 @@ type Chart struct {
Namespace string
RawValues []byte
Files []*chartutil.BufferedFile
Fs http.FileSystem
Copy link
Member

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)

Copy link
Contributor Author

@Pothulapati Pothulapati Nov 19, 2020

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:
Copy link
Member

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?

Copy link
Contributor Author

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.

jaeger/charts/jaeger/values.yaml Outdated Show resolved Hide resolved
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
@Pothulapati Pothulapati marked this pull request as ready for review November 19, 2020 11:45
@Pothulapati Pothulapati requested a review from a team as a code owner November 19, 2020 11:45
Signed-off-by: Tarun Pothulapati <[email protected]>
Signed-off-by: Tarun Pothulapati <[email protected]>
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]>
filename = filename[7:]
}
file, err := static.Templates.Open(filename)
file, err := fs.Open(filename)
Copy link
Member

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).

Copy link
Contributor Author

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.

Copy link
Member

@adleong adleong left a 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.

@Pothulapati
Copy link
Contributor Author

Pothulapati commented Nov 23, 2020

@adleong I am reverting the last commit, which involved the merging of c,Fs and c.DIr which added all this complexity.

I was trying to create a separate VFS generation specifically for jaeger chart by defining a JaegerTemplates but even that fails because of shurcooL/vfsgen#23

For Now, I will move jaeger chart to higher level charts directory so that even render works. We can raise separate PRs to fix this. WDYT?

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]>
Signed-off-by: Tarun Pothulapati <[email protected]>
Copy link
Member

@alpeb alpeb left a 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 😉

@adleong
Copy link
Member

adleong commented Nov 23, 2020

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.

@Pothulapati
Copy link
Contributor Author

Created #5278 with only the CLI changes. Will close this once both of them are merged!

@adleong adleong closed this Nov 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Move tracing chart into jaeger package
3 participants