0:00 <Untitled Chapter 1>

0:00 We're now streaming. Hello, and welcome back to the Rawkode Academy. I'm your host, David Flanagan. Although you probably know me as Rawkode from across the Internet. Today, we have another wonderful episode of Rawkode Live where we take a look at open source software that helps to make your lives easier and simpler in this cloud native landscape. Today, we are taking a look at a project called Helm Dashboard from a team at Commodore. And to guide us through our journey today, I'm joined by its creator and maintainer, Andre. Hello. Welcome. How are you? Hello. Hi, everyone. I'm super happy to join.

0:56 Closing Remarks

3:17 My name is Andre, and you probably know me by other open source projects that I've been doing in the past. And these days, I'm joining Commodore as a company and leading open source development in Commodore. Couple of words about Commodore. What what's the company? Commodore is producing the solution for easier troubleshooting and management in Kubernetes and everything that relates to Kubernetes. This is why the project that we are looking on today is also related to Kubernetes and Helm. And the project is Helm Dashboard. Should I start the presentation? Well, I'm curious. You said we may know

4:02 you from previous open source projects. Do wanna tell us a little bit more about your background there? What have you what have you worked on? Sure. I my open source journey was starting from the load pasting area where I was doing tooling around of a load pasting. And then I open sourced couple of interesting tools to do the either high scale load testing or lower scale, but with more details about around the visualization and analysis of the lower testing results. And so people inside the lower testing area know me. At least everyone knows the tools that I did, not necessarily

4:46 my person. Doesn't matter. And from there, I I found that it's actually exciting to start the projects and do open source in many different areas. For example, if you'll find my YouTube, you'll find there the robots built from Lego and the software library that is behind that, and that's the open source written in Python or some crazy experiments with chess and neural networks, and it's also open source. And some people who find it just have fun because I was writing the journaling all of my experience, which I cannot say is fully breakthrough, but just the fun of the process of

5:28 making it and sharing it with people. This is what excites me, and this is what led me to hear, basically. Alright. So I'm curious then. You said Lego robots. You said chess and machine learning. You've got a little of Python going on there. How did you end up in this Kubernetes landscape? How can you avoid Kubernetes these days? I don't know. Regardless of where you started in your past, you will end up with Kubernetes today because it's everywhere. This is the huge wave of transformation or at least adoption that comes in technology, in infrastructure. So anything that relates to Kubernetes will be

6:09 there for long these days. And I actually, several years, was looking at Kubernetes thinking, how will I apply myself to Kubernetes? What will I do in Kubernetes? And thanks to Commodore, I'm now able to actually meaningfully contribute to the ecosystem of Kubernetes. So I'm I'm all excited about Kubernetes. I like it. Awesome. That's wonderful to hear. So the announcement was this week, Commodore said in fact, was it yesterday? It's been such a weird week for me. Yeah. I think it was yesterday Commodore Helm Dashboard and this new project, and you're gonna guide us through it today. So without

6:50 further ado, I'll say, why don't you share your screen? We've got a few slides, and then we'll take a look at the project hands on. Alright. Let me start. So I prepared a couple of slides to guide us through the theoretical part of it, and then let's do some hands on demo. Let's do where's that button? It's there. Helm Dashboard by Commodore. The name supposed to be super obvious, nothing fancy. It's exactly that. It's the dashboard that shows Helm situation in your cluster. My plan for today is to introduce you to Helm if you don't know

7:44 what it is, explain the problem, why we started doing that, explain how we did how we solved that problem, do the live demo. If there are any questions, let's do answers let let's do an answer those questions hopefully with also live demo. This is what I like and prefer to do to answer the questions by demonstrating the answers, not prioritizing on it. First thing is let's remember what is this theme Commodore or Helm. And Helm is actually a cool thing, and it's a package manager. Usually, people describe Helm as reverse. They say that it's templating first. No. No. Its first

8:28 role, I would say the most important role, is package management for Kubernetes. It's actually a bit of shame on Kubernetes to not have an out of the box package manager because in any infrastructure level technology that appears in the recent days, you see that the package manager inevitably emerged from there. And, for example, Golang ecosystem, which I like, they started from having their own package manager and providing it. And other ecosystems like PHP, for for example, they didn't have any package manager for a while, and then the third party package manager appeared. The same thing happens to Commodore

9:18 to Kubernetes, I'm sorry, that the third party package manager had to emerge because the ecosystem itself didn't produce a package manager didn't introduce a standard. Maybe a good thing, in my opinion, there should be more centralized approach to package applications in Kubernetes, and and you should not need a third party for that. That's the history, and Helm appeared and became, I would say, de facto standard of parameterizing and packaging the applications. The how is it called? Kubernetes templating the default Customize? Customize. Yes. It it it appeared later, but it appeared too late because Helm has

10:12 already conquered the market, the the mindshare of the market and became the most popular way to deploy the applications. If we look into data, for example, among Commodore users, we see that % of our users use Helm. They maybe use it in conjunction with other technologies also, but they still use Helm. And second role of Helm is a contemplating language. It's a way to duplicate and parameterize your complicated Kubernetes manifest into something that is more manageable because it's great to have these microservice all loosely coupled things, but you have to manage them still as a holistic,

11:00 application. And today, Helm provides over 10,000 packages, thousands of repositories, and there is a single command line tool to operate it. In my opinion, it's good and bad because it's too many different things packaged into that CLI tool. But that's the standard. I cannot question the fact that Helm is the most popular way to package applications. And from that popularity, we have the whole ecosystem emerging from the community with plug ins to Helm, with applications, with their own vision of how you manage Helm or how you alter the way Helm's Helm applications are deployed. And it always starts great with the technology,

11:53 and problems come and troubles come when you start really adopting and using it. The problems that are happening with Helm, in my opinion, is they all they all originate from simple concepts that are used in really extensive fashion. In Helm, you have really small amount of concepts. A release a revision of that release, manifests values, everything is quite simple. But when you start using it on a daily fashion with multiple applications, many, different variants, and you add namespaces on top of it, multi cluster aspect on top of it, suddenly you feel that this CLI is cumbersome for you because it's hard to

12:00 The Problem

12:45 operate with these simple concepts multiplied by number of your applications, clusters, and namespaces. And I when I speak about this problem, I tend to divide it into into two areas. One area is that because of the Helm popularity, there are a lot of new users coming into this ecosystem, and they need, some more visual and simplified ways to learn. And if you only give them CLI, it becomes really hard for new and less experienced people to learn. I know from my past from these open source applications when, in the load testing area that the magic

13:32 of popularity comes when you respect the new users and you give them visual, easy, really easy to digest ways to learn your tool and your concepts. The experienced users on the other end, they also want some some visual presentation of the complicated things that they do because this is their daily efficiency. They already know all of these commands. It's just so long to run these commands, and I will demonstrate on the further slide what it actually means to perform quite simple operation and get answer to simple question with Helm CLI. And some people start immediately thinking how does this

14:18 idea of visualizing Helm plays in conjunction with automation and CICD. And I should say this is out of the scope for the project. The CICD and automation is already okay with CLI. It's meant to be used through CLI. It's for machines. It's great for machines to to operate with CLI. So we are not aiming to interfere with GitOps flow and CICD setups with this project. But we all know that when things are wrong and you need to do investigation through CLI, this is the when the amount of your CLI calls snowballs. And it's okay if your CLI results in

15:02 couple of lines of response. But in case of Helm, you have long, long manifests of Kubernetes objects produced as a result of these commands, huge JSONs, lists of revisions and charts. And all of that is really hard to manage, especially if you are under the stress of a failure. And this is where we want to help to experienced users also. This is your looking glass at your helm that's supposed to speed up your operations in case of troubles or just investigation. A funny story. When I started this project and first thing I did when I made

15:49 it just to view only capabilities of it, And we looked at our own staging cluster, and we actually found a couple of Helm charts that nobody knew that it's there. And we started asking, who knows what's that thing? Its age is two years, and nobody touched it since then. It's actually a dead thing. How could we know it without actually when it's exposed into our face through the UI? It's even easy to ignore it when you're in CLI. So that's the story. That's the motivation and the problem that we're trying to solve, to make things that you have

16:28 with regard to your Helm visual for you so it's easier to operate and easier to learn and get introduced into this ecosystem. This is that example. So I even omitted couple of commands to locate the Helm chart inside your chart, but now let's say we found that we have this Locky chart in the Locky namespace. And then to understand what has changed if you experiencing some problem and you want to understand what has changed in the recent releases of it, this is what you're left with. You need to generate these YAMLs. You need to store them into files, then

17:05 you need to call diff on those files. And if you generated the wrong revision, you want to roll back, your view to one more revision. You need to repeat all of that. And finally, the step number eight, you're doing rollback. And you see how many commands are there? And I'm not showing you the outputs of the commands, and usually those outputs are lengthy. So this is what we're trying to solve. We want to give the visual way to consume all of that information that Helm presents to us and have slightly easier way to manage your Helm cluster

17:42 your installations of Helm packaged applications in the cluster. And this is our approach to it. We generate we created this project which gives you the web UI because the web is the common way to to provide UIs today. And through that web UI, you can see what is there, what are the Helm charts installed, what's their state, what's their history, all of the aspects of those Helm charts. You can have the change intelligence. This is the most important thing, and this is this the the feature that comes or puts into all of its products into main

17:48 Helm Dashboard by Komodor

18:25 platform on of managing Kubernetes. What has changed? It's it's easy to get the answer, and I will demonstrate today how easy is that with Helm Dashboard to get the answer to the question of what has changed when certain feature, the flag or value was introduced. And also, can do some mainstream operations. You can roll back the revision. You can uninstall chart. You can install it, and you can reconfigure it. And all of that with preview. And one advanced feature that we wanted to include on top of the standard Helm functionality is the scanner integrations because

19:09 this is the thing that became the fact of standard in the industry to to scan your manifests and Kubernetes objects for the problems. So this is something that is a standard for today's operations with Kubernetes, and we integrated couple of code scanning or manifest scanning tools into Helm Dashboard, but that's an optional integration that you don't have to use if you don't want to. And, of course, it's all open source, free. There's no nothing that I'm showing today is closed source or anything like that. I I'm I'm the open source guy. I'm only doing open source

19:56 games. There are some existing solutions. Let's be fair. And today, I had a really funny morning because I woke up and then on LinkedIn, in one of the posts of announcing this project, one of the guys asked me the question, how does this compare to k nine s support of Helm? And I was like, does k nine s have Helm support? Did I miss something? And I went googling because I completely missed that thing. And I went googling, and I googled this, and I googled that, canine s helm, helm canine s. I found nothing. And I was curious. I went to the

19:57 Existing Solutions

20:37 canine s website, and I read through their docs. I searched through their docs. No mention of Helm. Then I opened K nine s and I typed colon Helm and it said there is Helm. And I'm like, wow. What's there? And it's it only shows the list of installed charts and the notes, the description of the chart, which is probably the least important information in the Helm chart. So it's there. The support for the Helm in k nine s is there. It's just well hidden. And this is what I responded to the guy who asked the question because this feature is extremely well

21:17 hidden. That's how how I react on that at first. And well, it's hard to compare k and n s because the the functionality there is really, really small. There are applications like Lens, Kubernetes dashboard, Kube apps, but the their problem is that the Helm is not a central thing. Usually, it's some something on the side. It's heavily bloated with a lot of features. And in my opinion, it's really hard if we look at that problem of helping new users to get into Helm. That's not the way, for new users to get introduced into ecosystem. It's

22:02 too heavy. A lot of those require much heavier processes of installing. While I would say that the simple user and even experienced user, they only need some sugar that you put on top of that Helm CLI, which is great. And here you go. And if we it's a popular question. How how does this relate to Argo CD? Well, the situation with Argo CD is actually much, much more tricky because ArgoCD doesn't use Helm when they deploy Helm applications. They only generate manifest, but then the the actual management is not done by Helm, which leads to losing some really crucial information

22:46 about the history of the chart. It's hard in Rawkode CD to find the diff between couple of revisions of the past. If you have that question, what led to a trouble. RUCD is more about GitOps, and it assumes that you will have your Git history to answer those questions. But between the chart and your Kubernetes, there is this step of generating manifests. So in my opinion, that's not always sufficient. And applications like Prencher and Codefresh, they attach the Helm functionality to some bigger beast requiring you to sign in, sign up, and have this huge beast and find in small

23:33 corner of it your Helm functionality. In my opinion, again, it's defocusing if you are just sort of starting with Helm. So this is the key in my vision of the Helm Dashboard project. The key is focus. Let's have a dashboard that is a UI over Helm. It's focused on Helm. It's Helm native, if you will, and it's easier for you to grasp the idea of what's going on there. So what we have at this stage of the project, and it's already there. We have the Golang application with web front end. It all runs locally on your computer. It uses your Kubernetes

24:21 context. It doesn't do any fishy things with secrets and access and sign ups. Nothing like that. If you have Helm working locally, kubectl working locally, that thing would also work using that same communication and configuration. It will recognize and respect your kubectl config files, so you will have your clusters listed there. All of the functionality that I mentioned earlier and I will show later, it's there. It's easy to install. It's made in a form it's shipped in the form of Helm plug in. So you install it and then you run Helm Dashboard, and it does the thing. It opens you

25:06 a browser tab with the application, and you can start right away. I will demo that. We have GitHub project. We have GitHub issues and Slack chat in as a support channels. So you can either live chat if you prefer that or use GitHub issues if you prefer that. I'm there, and ready and happy to answer some of your questions. We already have some questions and even pull requests, submitted by people, which is quite exciting. And we have energy and knowledge to improve it further. I have my road map. I partially expressed it into GitHub issues. If you want

25:44 to contribute something, there are a couple of simple issues to fix and maybe bigger features to contribute. I'm open for that collaboration with anyone who's interested in pushing this cool initiative forward. And with that, I think let's dive into live demo area where we will see the things live and going. David, any notes so far? Should I proceed, or do we need to make a pause? Maybe I spoke too much. No. I think you've described the project very well. I love all the context. I love all the history. I love that you've really nailed down to what the problem statement is

26:31 and how you think you can solve that and help people. So, like, I think that was a really good overview, and I'm looking forward now to actually seeing you use the product. Let's let's take a look at it. Okay. Great. So let's let me shut down the previous thing. Let's say I'm starting my next session of Helm Dashboard. This is my favorite part of all of these webinars and podcasts is the live demonstration. So the way to invoke it, I it it assumes that I've already installed that. There is installation instructions on the Helm Dashboard project page. There is this command you

27:10 want to install it. And Helm Dashboard is the command you you run to invoke it, and it pops up automatically the browser tab with your list of installed charts. On the left, you can see my clusters. I can switch to GKE, and I can switch this is my local default cluster of Kubernetes kind. So is that the context that you have in your KubeConf? Yes. Yes. Exactly. This is my KubeCon KubeConf KubeConfig context. So this is my JKE with the charts installed there, and this is my local kind cluster with the chart installed there. So

28:00 let's see what's the first thing we will we will do. Let's uninstall the chart or No. No. No. Yeah. Let's delete stuff. Come on. Let's be brief. We'll delete it. I think that we should go through the flow of the view view capabilities first because if I will delete the chart that has history, what will we view? So let's view. Let's see. I I have repaired the history for met metrics server. So I clicked on it, And you can already see how much information is in front of you even here without invoking too many commands.

28:39 You get you get all of that information. So all of this meta information about the chart, it's okay. But this is this is the valuable part on the left, for example. You can see the history of your chart, and you can immediately see that, for example, this was the downgrade and that lasted for three hours. Then after three hours, I upgraded it and it was lasting for fifty six minutes. And and this is the perspective that we're trying to put into Helm Dashboard that you most of the time so you don't care the absolute date of when the thing happened.

29:18 It was on twenty sixth or twenty seventh. It's more important for how long did it last. If it lived short life, then probably something was going on there. Somebody was reconfiguring it. If it was lasting for weeks or days at least, then probably it was a stable state, and it's a candidate to roll back to if you have problems. And you can see that here, for example, I rolled back and you can see the the icon designating that it was a rollback action. So you already start getting some more information than you get with bare Helm

29:56 command line that you run. Don't get me wrong. This thing runs Helm under the hood. It just mixes it with a lot of sugar and presents you a nice birthday cake as opposed to the sugar and flour separated. So this is the this is the idea. And from here, we can do either actions or we can view different aspects of this Helm chart that is installed. Let's view the aspects of the Helm chart. First, we can see the current resources in the Kubernetes cluster. We can even describe those resources and see the described view of those resources to spot,

30:42 I don't know, events or problems that are running right now. And this is the first view. The second view is the manifest. This is where you start digging into problems and you your problems usually originate from manifest. But in manifest, a lot of times you don't want to just look through the manifest YAML. It's quite tedious unless you know what you're looking for. You rather would look for the div. Nice. And for example, you may see that I was introducing the wrong command line and then rolling back. What was the meaning of this rollback? I rolled back

31:18 to the working state from intentionally non working state. And if I just click here, you can see what was that upgrade of chart revision. It led it resulted in some annotations and it should also be resulting in some image upgrades. And you can see this is this was my malicious option introduced here. So this is this is cost you only one click. What was this? What was that? Why why this didn't upgrade or didn't didn't downgrade? This is because I reconfigured it. And this one is obviously the installation, the first step. When I was reconfiguring it, was it originating

32:04 from anything else or just my actions? Then we can switch into values and see what was my, let's switch user defined values only. This is what I did. This is exactly my change. And it becomes important if you collaborate and multiple people do multiple changes to the cluster. This is how you figure it out in case you have questions to what was the story of evolution of this chart. So this was the reconfiguration that broke it. This was the rollback that fixed it back. And all of that with just mouse clicks. Super easy. The notes, as I said, is

32:46 probably the least interesting part of every chart. Nevertheless, it's there. So this is the viewing capabilities. And this is the place where we'll probably look at the integration with scanners, the code scanners. There's this button. You can describe the resource and you can also scan. So if I if you have locally installed Chekov and Trivy or one of these problem scanner, you can click on the button and it would trigger the check of that Kubernetes resource for you. So you can review what Chekhov thinks about this specific chart and Kubernetes resource, and you can also know what Trivy thinks

33:32 about it. And they look at it from different perspectives. The reports are huge, and you can review that. But this is your access to this normal today question of do I have any troubles? Do I have any high priority troubles here? Criticals. Do I have criticals? No. There's only one critical. Well, probably criticals and highs are to fee to be fixed. Maybe I should upgrade something or at least keep an eye on it. Let's go further. How do we reconfigure? There's this button that you can just click, and it would reconfigure your the application. For example, there is this

34:19 already existing value. I can, by the way, downgrade the app from this screen. If I really want, I can go back to the previous version, like or I can upgrade from the same view if I want, if there is a newer version. And what's important, this is where we assemble together different sources of the information about the chart, and we allow you to manage the upgrade, downgrade, or modification process of the chart with everything you need at your hand. For example, if you don't know what is the parameter that would scale this thing up, you can

34:58 look it up here. This is your documentation from the chart. What's the name of my replicas? Okay. This is the name. I can just put it here and say replicas five. Okay. Let's not kill my machine. Let's say replicas two. And down below, you will see how you how my manifest changes. It will actually change one parameter here. What if I downgrade to very old version? You can actually review that there will be some more changes than just image versions changing if you do downgrade. And everything happens, you see this before you do it. And this is super important

35:38 because the the vicious cycle of doing a mistake and reviewing resulting failure and doing a mistake in in configuration again And all of that, it's not good. But Helm offers you quite painful CLI based process of reviewing these changes. So we're just taking all of that experience and assembling it into a nice UI that allows you to review before you install. And it also allows you to scan for problems before you install. If I click this button, then there this whole manifest will be run through Chekhov scan and it and you will see what Chekhov

36:26 offers you as list of the problems to fix in your in your manifest that you are about to deploy into your Kubernetes cluster. If you want to do something about it, do something about it. If you just review and accept, you just push the button confirm and it would apply to your cluster. It would apply to your cluster, the changes. And you can review. This is our new revision, and you can see that the changes that you were seeing in preview, those were actually applying here. And I guess it it it starts the second replica right now for us. The values, did

37:15 we change anything? Yes. We we set two replicas now. All of that is quite expected. And note, now when we have downgraded, it looks into repository and says, don't you want to upgrade? You are actually not at the latest. And there is even a nice button to check for a new version. By the way, there's a trick. I know that today Commodore has released a new version of its agent. So now I can demonstrate you how the check for new revision for new version works because it's it only works once when it finds the new version. I will I will show you

37:55 that. So what else can we do? We can roll it back to the previous revision or we can select the revision and roll it back to something that was that we considered great. No. This wasn't great, and I think this one will be alright. Let's do a rollback. When you do the rollback, it tells you what will be changed again before you rollback. And let's review. Let's see what are the command line options. Command line options actually do not change, but there are some defaults that were introduced by the chart. Okay. I accept it, and I roll it back to the previous

38:39 state. It has created the new revision. This is how Helm works. When you roll back, it doesn't erase anything. It just creates the new revision. It marks it as rollback. And finally, we can uninstall this chart, but I will not uninstall it because it's beautiful and it has so many revisions. I would rather uninstall something that I value slightly less, that I invested some less resources and efforts. Let's do Grafana. Grafana, you are uninstalled. Well, it's obvious. It tells you what you will erase from your cluster and confirm there's no Grafana anymore. And again, since it runs

39:23 actual Helm behind the scenes, this is not something that can desync with Helm information. It's always in sync because it uses the the actual Helm information inside it. It's not a custom database or whatever. But you usually start with no Helm charts if you are a new user. Right? So what do you do? You have this repository section where you can actually see the the repositories you have. You can add the repository and you can install. Let's go to Grafana, and let's install Grafana. This is the repository that I have added for Grafana upfront. And I just click install.

40:12 We get the familiar screen where we can change Grafana pipe. And we can see if we want some values. Let's do the same replicas. Cluster role. This is the preview of what will happen. Let's do replicas one, replicas two again. It will recalculate the diff for me and all of that. What else? We can do interesting thing. Let's do the Rawk not created. False. You see how I don't know if you live this life of Helm documentation. How do I configure it here and there. And it's so easy. It becomes even for me, I I spent less time playing with these

41:08 things and operating Kubernetes, but it's so pleasant for me to simplify the life and see this documentation and edit this documentation and preview the changes. So let's go ahead. Let's install, and it should install me the new Grafana. And now this Grafana awaits for containers to be created and become available. We can look at it. It now scaling replica set to two. So it knows what I asked it for, and in a couple of minutes, it will make it available. So now I can reconfigure for for example, if I'm not patient. Let's get back to creating.

41:57 By the way, you see each time you update Grafana Helm chart, it regenerates your admin password. This is a finding for me, which is surprising because I that's not what I wanted to find. But now I know something about Grafana, one one small piece. So it would add a bunch of new objects into my cluster. Let's do that, and let's see that everything works. Well, it cannot keep up with the pace of my changes, but I'm alright with that. And as always, you get these navigation through revisions, and it's so much different from what you

42:34 get from CLI. I don't know. What else what else can we do here? Let me see the scans, the resources, the manifest, the values, the change viewing, And I think it is. I promised you to show how now it thinks that I'm on latest and this is actually one of the frequent change frequent use cases that we hear if you read the Kubernetes Slack community, people come and they say, have my Helm charts. How do I easier check for the new version to exist? And is quite frequent use case. This is why we added this button, check for new revision.

43:23 I know there is. Now I can upgrade. So I don't need to leave this screen and leave this context to quickly check for the new version to exist. And now I can upgrade to this new version and go ahead and it all happens without losing the context because this is what important in these complicated environments when you have so many basic entities, but they are all interconnected and there is historical perspective. It's important to not lose the context and be able to go back and easily navigate. And this is what we provide with Helm Dashboard. Much, much more easy navigation

44:07 through Helm concepts while everything under the hood is % Helm compatible and it's true Helm inside. So we're not inventing something weird and incompatible with what we do. And basically, this is it. This is my demonstration. So if you have any questions, should I I'll be I'll be able demonstrate you the answers if if it's demonstrable here. Alright. Awesome. Thank you. I think, you know, I don't have a lot of questions because every time something in my head popped up, you were moving right onto it right afterwards. So it's like your demo just gonna flow it really well. It introduced us

44:50 to all of the features of Helm Dashboard, which I just think is a really pleasant way to manage what is otherwise a very not complicated, but cumbersome It's tedious. Right? You know, it's It's tedious. Yeah. Yeah. And I I I love is that you know, the wild feature here is that comparing the previous revisions, comparing the previous values. Because those are the things that ruin my day when I mess around with Helm charts. It's like, oh, I didn't know it was going to do that. And you know what? See that Grafana one with the regenerated password?

45:22 I ran into that a few months ago and it was infuriating. And it took me ages to work out what was actually going on. So Yes. Here here you you will you will see that suddenly the password has changed. This is your problem. Exactly. Yeah. Because the chart generates that every time you run it and it's, yeah, very frustrating. And that you only find that out when you when you go off the kind of the standard path near using Helm template and other things. But, yeah, that could def with previous for the manifest and the values.

45:52 It's a very, very cool resource. Something I wish that I had had in the past. Awesome feature. The one thing that you haven't answered that I'm curious of how Helm Dashboard handles that or supports that or whether it doesn't is Helm Hooks. Is there any integration to show me what's gonna happen with the Hooks when I do a Helm deploy? I haven't got to this aspect of Helm yet, and I will review that in the future. I I saw that the Helm hooks it it's not really used too widely, and this is why I prioritize it later.

46:33 And I tried to implement the other features that I believe the more mainstream features first. But it's for me, it's interesting to sort out even these edge cases because I want the advanced users to also benefit from this project and from this functionality and not only the very basic users. Awesome. So that's definitely planned. Another potential feature for the future, not right now because it's still very early, but charts that there's the new feature with Helm that allows people to annotate the values dot YAML with schema information. And I like when I see if you can go back to the values

47:16 bit. Yes. Sure. Yeah. From, like, here, it would be really cool if you were able to process that schema information and make it a bit more of a rich editing experience. I think that Do you do you mean the these comments or it's something even more than that? Yeah. The let me see if I can find you a quick example. While I did that, if anyone in the audience has any questions or just wants to say thank you or awesome in the comments for the demo, please feel free to do that now. Well, I very quickly try and find something that has

47:49 it. Let's see. I came across this recently. Well, it's if it's something standardized, cool, and useful, I'll definitely as I see, if if there is the schema for this thing, then I would love to, on the fly, apply it to these values and warn you that you misconfiguring it, even before you do that. Yeah. Let me So if I got the idea, then it will be okay. Let me I'll share my screen for just a second. Sure. Sure. Go ahead. Well, can you see? Yeah. So this is the so the bitnami charts, I think, are quite good for doing the

48:39 schema thing. But you can click on this value schema here, and it actually tells you the types that you should expect. Mhmm. So here, we got string. Here, got an object, which then, you know, got properties and stuff. So this information is available. And if I remember correctly, it's it's really horrible and that is comments within the YAML. But then, I guess, what else are they gonna do? But if we jump to I can never remember how you got to the the source code from the artifact hub. It's actually in the Helm itself, it's quite

49:15 inconvenient to get to the original chart of that produced some release. And I'm quite surprised that they didn't introduce any kind of unique IDs to interconnect in a reliable way. It's all name based, but it is what it is. If we all remember the history, it was a hackathon project that started Helm. So Yeah. So and our values dot YAML, we have all of these comments which have parameter information, which then ties up with this schema JSON schema document that we have here. So there's a whole bunch of information there that it would be awesome to get into

49:59 Helm Dashboard and really annotate and augment what you already have with, like, this rich interface. I think that would be awesome. So there's my feature. That sounds interesting. That sounds usually, I I should warn you. One thing that I really want to avoid is to turn in turn this Helm Dashboard, which feels lightweight and easy, into a piece that will be, like, really heavy over overflowing with these features. So Yeah. That's my mindset at this moment because I see there are alternatives with a lot of functionalities super, super rich, but the the dark side of it is that it

50:42 becomes really hard to navigate and heavy to operate, and I don't want that. I want really to speed up the process of operating for people. But if it helps if if your idea helps the process, I I will review it. And if it helps the process, we'll definitely do that. Alright. Or somebody will contribute it. It's an open source for sure. Alright. Awesome. Well, what I'll say is I love what I've seen. The levers straight up value to people that are deploying Helm Trust to the cluster. Again, that ability to see the revisions, how the templates have been modified, and how

51:20 my user and the value has made and really highlight what those changes are, I think makes operating and working with Helm and our production like environment using the dashboard a fantastic experience. So I'll say kudos. Really cool project. Hope most people take advantage of it. I hope people get involved and contribute open issues, pull requests, all of the above. So the it's under GitHub.com. Is it /Commodore? Sorry. I wasn't pinned. Yes. It's Commodorei0/Helm Dashboard. If you will Google Helm Dashboard Commodore, three words, then it will distinguish this project for you from some other parts of the Kubernetes and dashboard

52:03 universe. Hound Dashboard by Commodore, this this is what you need to remember. Awesome. Then I'll finish up with one last question, and then I'll let you get back to your day. Like, you said at the start, you you have a road map. You've got a a bunch of ideas that you you kinda wanna work on. Do wanna share a little bit of details about maybe what's your your top priority? What's coming next? What people should expect? Let me see the it's easy to read from the list of written written things. Well, there is there are a couple of items that are really

52:38 tough. And to impress you, I can mention these tough items. For example, this Argo CD problem that so many people use Argo CD and they use Helm deployments for that, but Argo CD doesn't use Helm, so there's no meta information in secrets where Helm stores it. So Helm doesn't see these charts. The question is, can we somehow still traverse through objects in or query Kubernetes for some labels and annotation and still show these objects to people. So they if they are looking for that information about Helm charts, they will get at least something, at least some view to,

53:23 their by fact, it's a Helm originating thing, just Argo CD does it differently. So that's one hard item on the road map to find what can we do and how can we still visualize those charts for people. Another problem that that we have is we need to integrate with more artifact or manifest scanners because I know that different people prefer different kinds of scanning for manifests, so we should provide more variants of scanning the the resources. There is the advanced case of umbrella chart that we now only display the first level of umbrella chart, and there is the

54:14 heavy advanced case of multiple charts dependent on each other. So we need to review that. And I think we will get to those advanced questions as soon as we fix first layer of feature requests that are already coming people coming with these really cool and practical feature requests. And I will always prioritize users' feature requests, really makes sense and comes from the field and from the community over some of my theoretical ideas that I would love to do. And, again, that's the mindset of open source veteran, if you will. Awesome. Well, all of that sounds good. Like, I

54:58 think all of that sounds great. Let me fix my own language. Yeah. You're right about the Argo CD thing. I bet you could hook in to the Argo custom resources and get enough information there. I think that's gonna be a fun but challenging thing to do. So I'm excited to see how you look into that. And, again, give people a single pane of glass for all of their Helm Dashboard. I think that'll be yeah. But like you said, it's gonna be a hard problem to solve, but a useful one for people, especially as has got so

55:26 much interest and adoption across it. And I wonder if that would even help with the Helm resource as well. Although, I can't remember uses I I already got one of the issues from that Flux user, and I see that Flux did something nonstandard to the Helm the way they operated, and there is an issue. And we have it's actually a really nice discussion. You can go and read it, and you will see that we we have some idea how to work around the problem as a quick win, and it's still open question how to solve

56:07 that or if it if it's even solvable on the general level. Well, thank you for taking the time to join me today for working on Helm Dashboard for showing people how to make their lives easier and for all the future work that you're about to accomplish to make it even better across all of this. Let's face it. Cloud native is this. We have so many different systems, so many different ways to do this thing. You're working on a very noble cause. Well, thank you for that. I would say, please reach out to us again when you've

56:39 got any major updates to Helm Dashboard so that we can show people how to get started. And I encourage anyone watching this episode to go check out the repository, open issues, and get involved. So, Andre, thank you again. Have a wonderful day. And do you have any last words? It was a pleasure demoing to you. Thank you very much, David, for inviting me. I'm I'm excited to be connected to the community and and share all of these applications. Let's hope this is not last of our projects and not last of our initiatives because I I really love starting these open

57:13 source projects and letting them accessible to the people and by that changing and moving forward the ecosystem and the technology world. Cool. Let's all do open source and contribute at least with your feedback. Awesome. Thank you. Alright. Everyone watching, remember to say thank you in the comments. We'll see you all next time. Thank you again, Andre. Everyone, have a wonderful day. Thank you. Bye.