-
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
✨ Add Cluster API Visualizer to Tilt observability #6593
Conversation
@killianmuldoon PTAL when you get the chance. I set it up so we read from the chart directory produced by tilt-prepare so far. The secret in the Helm chart requires the kubeconfig, which is computed at runtime, to be set as a value in the Helm chart. I tried to use the yaml output in .tiltbuild but it's not very straightforward to try to get the secret working. |
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.
Overall lgtm, only a couple of nits from my side, mostly to:
- drop
cluster-api
in front ofcluster-api-visualizer
- use
visualizer
consistently (thus dropping the "visualize-cluster" variants).
Also, please add the new option in https://main.cluster-api.sigs.k8s.io/developer/tilt.html#create-a-tilt-settings-file where allowed values for deploy_observability
are documented.
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
/hold
@Jont828 Thanks for this! could you squash the commits when you get a chance?
@killianmuldoon Just squashed! |
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 tried this locally and looks like there is a bug.
If the list of deploy_observability
only has visualizer
in it then the visualizer resource fails with the following error:
Build Failed: namespaces "observability" not found
Seems to be working fine if any of the other observability items are in the list.
It would be nice to be able to use just the visualizer without having to deploy the other items as well.
@ykakarap Just pushed some changes to create the observability namespace before deploying the visualizer chart. I tested it locally but let me know if it works on your end! |
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.
@ykakarap Just pushed some changes to create the observability namespace before deploying the visualizer chart. I tested it locally but let me know if it works on your end!
Tested it and it is working as expected.
/lgtm
Great work on this!
key: app | ||
value: visualizer | ||
|
||
kubeconfig: "\"${KUBECONFIG_DATA}\"" |
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.
How does this work?
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.
Maybe I'm doing something wrong but the visualizer doesn't work out-of-the box on my machine
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.
The tilt-prepare code wants to build the Helm chart into a YAML into .tiltbuild, but I had trouble getting that working. Instead, I'm not really using this values.yaml file and I'm using the helm()
function in the Tiltfile to load the Helm chart. What's the error you're getting?
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.
The tilt-prepare code wants to build the Helm chart into a YAML into .tiltbuild, but I had trouble getting that working.
That works for me. What error are you getting?
I would really prefer deploying this Helm Chart the same way we deploy all others.
What's the error you're getting?
I was trying to deploy the Helm Chart like the others. Which worked, but then kubeconfig
was not set correctly, which kind of makes sense :)
WDYT about if we try to resolve this issue #6286 instead of passing in a kubeconfig via values / a Secret? It's just such an anti-pattern to use a kubeconfig from a Secret instead of a ServiceAccount with RBAC.
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.
+1 to resolve #6228 first if this can avoid differences with other charts
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 think the idea would be to introduce InClusterConfig() into the Visualizer. That would allow the binary access to the kubeconfig associated with the pod's service account.
The visualizer is using clusterctl as a library IIRC. Also IIRC the clusterctl lib currently only takes a kubeconfig as input which is something that we should probably fix/improve (I didn't take a closer look yet, will do that later/soon)
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.
@Jont828 I think I have an idea how the visualizer could already have a good kubeconfig/inCluster discovery behavior even before clusterctl supports it.
If it's okay for you I can do a POC and open a PR for the visualizer. WDYT?
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.
Sure thing! I'm happy to pair on this sometimes as well if that's easier.
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 think there are two ways this can be resolved:
- Workaround the current clusterctl implementation and use the clusterctl lib as is
- Refactor clusterctl to e.g. take a rest.Config as parameter instead of a kubeconfig file
I think 1. can be a short-term solution and a quick win. 2. probably requires more time/discussion (I also commented one the issue).
I think 1. could be done like this:
On a high level in the visualizer main.go
restConfig := ctrl.GetConfigOrDie()
# write restConfig in kubeconfig format to kubeconfigPath file
c.ClusterClient = cluster.New(cluster.Kubeconfig{Path: kubeconfigPath}, configClient)
In my opinion GetConfigOrDie from controller-runtime has a very nice behavior and it would have the added benefit that the visualizer handles kubeconfig like every other controller. It's documented in detail here: https://github.com/kubernetes-sigs/controller-runtime/blob/master/pkg/client/config/config.go#L63-L91
Once 2. is implemented we can move the visualizer away from the workaround.
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.
Thx for accepting the hacky workaround :). We should really improve the clusterctl lib so that you can get rid of it again.
Works for me. lgtm pending squash Disclaimer: I had to delete the |
cc @fabriziopandini @ykakarap @killianmuldoon PTAL |
# Overrides the image tag whose default is the chart appVersion. | ||
tag: "v0.1.0-alpha.2" |
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'm ok with this, but in the future, I would like the chart to always give us the latest version, so we are not required to keep this value up to date; see Jont828/cluster-api-visualizer#6
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.
Sounds good, I'm working towards a v1 of the app with the clusterctl changes from CAPI 1.2 so I'll rework the Helm chart then.
Looks great! lgtm pending squash |
/lgtm |
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
Great work! 🙂
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fabriziopandini The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/hold cancel |
Thanks to everyone for helping me test this out! |
What this PR does / why we need it: This PR adds the Cluster API Visualizer app to Tilt under the observability section. It can be enabled by adding "cluster-api-visualizer" to the "deploy_observability" array. The Tilt UI looks as follows and the "View visualization" link opens it in the browser.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #