 Okay, cool, hey everybody, you're here because you are interested in learning the Helm code base for various reasons. Hopefully, part of it is to help review pull requests so that you can get the features that you want into Helm that are already in open pull requests and they're probably about 300 of the 300 something now. So we appreciate your interest and your help. So I'm Scott Rigby. I am a developer advocate currently working nowhere and I'm a Helm maintainer. I have been since 2016 or so. When I really started working with the charts repo, if any of you remember the stable incubator charts repos, that was really a big part of what I initially did. But, you know, involved in various levels of Helm. And, yeah. I'm Karina Angel, I'm one of the Helm web maintainers. Been involved for a couple of years now. I don't know, time is a weird construct right now. And I- What is time? What is time? I currently work for Red Hat and Andy. Yeah, hey everyone. Andy Block, a distinguished architect at Red Hat also with Karina. I have been a chart maintainer for a year. And in the chart community for a few years, my focus in the project is enhancing and improving OCI integration. So using OCI and storing charts within OCI registries is my primary focus, as well as just general contribution to the project. And I do want to quickly point out that we have two other maintainers that I can see right now. They're in the front row. So if you have more questions, you can find them later too. Oh, she just threw you under the bus. And Martin, if you don't know Martin, he was a huge influence on the three to four migration. Two to three, sorry. Yeah, yeah, yeah. Yeah, so we're gonna start with it. This is just the agenda for today. Most of this we're gonna go rather quickly through and we're gonna focus most of our time on exploring the Helm code base and depth. But it's important to set up a few of these things a bit and then kind of help say, well, then what do you do next? Yeah, so what is Helm? So Helm is a package manager. It sounds like, okay, who doesn't, wait, who knows what Helm is and who uses Helm already? Okay. When you come to an event like KubeCon, you never know who's gonna show up. It might be their first foray into Kubernetes. Let's go ahead and let's start with the primitive. Exactly. Who here has not heard or used Helm? Raise your hand. So for the people that are watching this recording later, just be really short about it. Helm is a package manager for Kubernetes. It helps primarily package applications and allows you to deploy those and it has other lots of handy features that allows you to basically work with the entire lifecycle of an application in Kubernetes. But yeah, it's also like, it really is a great way to share and people come to Helm for different reasons, but one of the reasons that folks come to Helm is to actually learn Kubernetes to try to reverse engineer charts to understand what do these manifests even mean? And we have a lot of users like that. We have other users who are developing their own charts. The vast majority of people just say, Helm install blah and they never think about it. And then we've got people that are helping on the development side, on Helm itself, like the binary, and the Helm tooling. So we'll go over some of that in a few. So Helm has been around since 2016 and became a graduated project in 2020. And since then, once you become a mature graduated project, one of the things that happens is you have a lot more users and not as many maintainers. So having, walking through this PR process as you are anxiously waiting for your pull requests to be reviewed and merged, it's good to, I'm glad you're all here, kind of walk through this and help understand that we do need more people to help review and triage. We care about all of these pull requests. We just, time doesn't sit still. We're getting there. Yes. So like breeze through some of this, basically, I think it sounds like, okay, I'm kind of thinking that maybe it would be good to be. I think we skipped some slides. Yeah, just to skip a couple of these and like jump right into it because everybody here is familiar with Helm and why it matters for Kubernetes. We'll like get to the meat of why we're here. Okay, so you know that Helm allows you to install applications in Kubernetes. Okay, let's get to where we are. I mean, this is actually probably pretty good to just to mention to folks like, because this will help with the introduction to the code base, just to talk about the different parts of Helm very briefly or outline them. So generally, when we're talking about Helm, it is a CNCF project, but it's also a bunch of different things. So when people describe Helm, they mean the Helm binary that lives at github.com. Helm Helm, or when you just say help, you use the imperative help command. That's really what we mean by CLI. Then there are Helm charts, right? And those now are distributed. They don't live in one place even though they used to live in one repo. Now they're quite distributed and we generally use artifact hub to find them. Helm also, the other part of Helm is the Helm templates themselves. And they really, for those who are wondering the templating functionality is, if there's anybody wondering, it's primarily for helping people just templatize animals so you don't have to type all that by hand and allow some simple options. The Helm values are those options, that the options file, as most of you know, but we'll still say them real quick. Releases are the, when you do a Helm install, you can install, let's say, Bitnami WordPress or any other chart and you can install that multiple times. Each of those instances is a release. And ultimately there are revisions. So Helm keeps track of revisions. Those metadata, those metadata, sorry, those revisions are stored in as metadata in secrets, generally within the namespace where the chart's deployed. So just reviewing that for a second because we'll kind of get to some of this as a code base. So Helm project is comprised of several different repositories. You have the primary Helm repository where most of you will probably spend most of your time. We have Helm dub dub dub, which is gonna be where the contents of our website live. We have a couple different tools that help support the Helm code base. One of them is Helm testing, which allows you to do some test-driven user sanity checking. So it does some linting. It'll also do some integration testing to make sure that your chart will be deployed successfully to a Kubernetes cluster. If you're using it within like GitHub Actions or your CI, you'll potentially spin up a kind cluster as they showed today during the keynote. A Helm Releaser is gonna be where you, it helps make a chart release using GitHub. So if you're using GitHub, there's a automated process that will help you create a chart repository within GitHub Pages. Easy, simple way to get a chart repository out there. We have a number of GitHub Actions that help support Helm itself. And then we also have Chart Museum, which is another project that allows you to store your charts. So if you didn't wanna use GitHub Pages, you can go ahead and deploy Chart Museum within your organization. If you happen to be interested in deploying one, and stand that up. There are many different ways to contribute to Helm. You don't necessarily have to be a coder, but you can go ahead and propose certain things. So let's say you had an interesting idea for a new feature. Let's say you're a project manager and you say, hey, I got a team. I keep hearing all these issues. I can go ahead and create a proposal. If you wanna then go ahead and perform some changes, you can go ahead and create features. You can enhance the code base. We love that because nothing like evolving forward. If you find a bug, because Helm wouldn't have bugs, would they? It's perfect, right? Those numbers. It's pretty stable. It's pretty stable, but still, if you find a bug, you can go ahead and contribute. If you're a bug report, you can go ahead and fix a bug, please. If you find a bug, please fix it. We'll get to it. Or most importantly, like any open source project, you can contribute documentation. We love documentation. It's how others in the community learn about Helm, learn how to use it. So there are different ways that you can start getting involved in the Helm project. It doesn't have to just be go-lane code. And translations, we love translations too. Now, that would be amazing. If anyone is a fluent speaker of a different language, we'd love to talk to you about going in and helping contribute some different languages because we wanna help expand the amount of a user base and putting it into their own natural language makes it easier for them to pick it up. I think I'm gonna try to breeze over some of these so we can really dive into the code base. Sure, let me just talk about HIP. So basically, if you have a new idea or new feature, you can create a HIP. A HIP is a Helm improvement proposal. So you can go ahead and propose how to improve the Helm code base. There are three different types. If you go to the next slide, Scott. Yeah. Basically, there's a new feature. So if you wanna have some kind of new implementation to Helm, there's, if you have some kind of information that you wanna make it easier for others to understand for Helm, or if there's a way of working with Helm, that's another type of HIP that you can go ahead and create. Yeah, and they're similar to PIPs. Basically, that was part of the, you know, the inspiration. In the Python world. Python and ultimately an RFC. But this is also pretty important when reviewing pull requests because, you know, often someone's going to open up a pull request with major changes. And generally one of the maintenance will say, ooh, that looks like a pretty major, that looks like a pretty major change. Have you talked with anyone about why, you know, how this, what else would this would affect, et cetera. And will often suggest that someone open up a HIP. An improvement proposal. So yeah, I can cover this if you want. Like there's really several types of rules for people who are actually working on the Helm project itself. Primarily, we've got, and we'll get to the why on this for a second, but we've got the subproject maintainer, which is someone who maintains just one, either repo or set of repos within Helm that comprises a subproject like Shark Museum, or like if you're part of the Helm, excuse me, part of the charts and chart tooling team, then you may be maintaining several repos like the GitHub Actions chart releaser, that the GitHub Actions wrap, chart testing, et cetera. So that's a subproject maintainer. Triage maintainer is one of the things that we've highlighted in past project maintainer track talks like this to say, hey, we really want folks to, we wanna help people, help enable people to help with the pull request and issue process. And so that's what triage is for. GitHub has the triage role, and what it allows you to do is do things like help with labeling and things that not everyone in the community can do, only approve people like run the testing suite, et cetera. So only specific people who have shown that they are really interested in this and are trustworthy and they can help just not make a mess of things can start by reviewing pull requests and helping on that side of things. And then we have open positions for triage maintainers. So that's really what we're, the area that we're hoping to grow the most. We have Helm Core maintainer, and that's something that people certainly can work to, especially if you're doing triaging for a long time. We'll walk you about later on. Yeah, yeah, yeah. There's different ways to do that, but there's basically the Core maintainer, that's the github.com Helm Helm, right? And then there's a community manager role. I believe right now we have one, and that is Karen, right, yay. And there's a blog post from a little while back explaining that and what that role is about. And then there are org maintainer roles. And those are a handful of people that guide the vision of the Helm project and help with things like governance. And really it's just a point of escalation, mostly for governance for the CNCF project. Yeah, I'll take it. Okay, great. Oh, it doesn't mean that I'm gonna talk about it. I'm dying. No, no, no, no, no, no, no, no, no, no, no, no. Don't worry, I was just gonna do it. So Helm's primary code base are broken up into several sections. And I'm at least gonna start with, and I'll probably turn it over to Scott, who's gonna really kind of dive into the different code base. First of all, like most open source projects, you have the .github folder, which is gonna contain all your GitHub metadata and repository assets. We then have the CMD Helm, that's gonna be where our command line tooling or the command line components are located primarily. We have our internal package, which is gonna be more of the internal core capabilities of the Helm utility is found. You then have our PKG, that's gonna be where a lot of the SDK is exposed. So if you are working with integrating Helm into your own project, you're gonna be leveraging a lot of the code that is part of the PKG folder. We then have two other ancillary part of Helm, pardon me. We have scripts, it's gonna be some tooling that's available for testing, releasing, all that's in there. And then finally, some test data so that helps support testing because everyone loves testing, making sure that everything works as we expected. How many people actually do tests? I wanna see more hands. I wanna see more hands next year. Please, more tests. Thank you. I'll take both. You wanna walk through some of the... Absolutely, yeah. It's important to note that this is something that gets confused a lot and people that are opening PRs and trying to contribute to Helm, they wanna, you wanna have your feature in there or someone else wants to have their feature or you are not, it's member who's like, there's this PR that's been open for a year, what's going on? So sometimes this gets confused. So where do you put the actual functionality? Like where do you put the feature? And the most important thing that, well, one of the most important things that gets lost often is that we need to support both both people that are consuming the Helm SDK, projects like Flux, project like Rancher, different projects that are ultimately just using what's under the hood to run Helm, not shelling out to the command line. The command line, the actual commands, the Cobra commands and they use the SDK as well. So they use the exact same underlying libraries as you would if you were a consumer. But we need to make sure that when functionality goes into the code base to either fix a bug or improve, enhance something that we are thinking about both of those users because the vast majority of users are users that use the command line when you're typing in Helm imperatively or it's maybe in some CI process or something like that. But there are a growing number of tools that are using the Helm SDK and a lot of you probably rely on those too. So it's really critical to make sure that, let's say when something needs to be fixed and it's not command specific that we look at, can that be done in the SDK, excuse me, in the underlying packages? Usually the answer is it probably should as opposed to say trying to do it just in the command packages because then you're fixing the bug just for the command line and that bug isn't really being taken care of for someone who's a project that's consuming that same functionality. There's a good chance that some people, some of you in the audience are consuming it either within your own work or your organization's work. Oh, and did I, actually would you mind going back? One, so okay, so we all probably, we're gonna assume a certain level of go knowledge here because we can't cover that in a certain level of Kubernetes knowledge, but so perhaps the internal package is obvious but just to call it out real fast, it is things, those are things that are not exposed to the public and we do that so that we can, some internal packages so that those can continue to change without breaking our backwards compatibility contract. The, yeah, I think that's actually it and that's on this slide that I wanted to say. Yeah, these are all, this is where all the automation lives and we do need help with that too at times so just know that it's in there and there's a lot that can, we can dig into that but I think it's probably best to kind of like give you an overview of basically where the kinds of, where the code for the kinds of pull requests that are open are really helpful. This is gonna just contain your full standard with most open source projects, we just wanted to emphasize it for completion. Yeah, and we do have the project pavilion, we have a booth in the project pavilion in the afternoons and we'll have our laptops there and we can dive further into actual specifics too. Yeah, and so this is really where, this is an example of. This is where the Cobra packages live so how many people are using Cobra in their own projects? Yeah, it's a common tool that's used in most goal lane based projects, a lot of projects in Kubernetes use it. Coupe control. Everything uses it, so we're just going ahead and showing that this is where most of this code currently lives and it's a very standard structure. Actually would you mind going back one, this is just kind of important to say so this list will keep going down, this is just a screenshot of it because we didn't want the internet to go down. It's super long. Yeah, it's all of the help commands. So basically when essentially everything, excuse me, inside of the command folder there's a, you'll pretty much know where the commands are because they're named after the commands and they're sub commands and each of those have a test file as well to go with them. That might be obvious for most people looking at this but just in case it's not, I just wanted to point that out. So it can kind of help you understand where at least your entry point is for the CLI. This is the no talk internal packages of Helm, which were all of our code that we see that we can change without breaking that back across compatibility, it's all gonna be living in here. So everything from some of the utilities that we leveraged, some of the file utility, some of the basically just how we do parsing as well as how we resolve packages are in charts because that's really important. As someone who spent a lot of time on OCI integration resolving packages is challenging whether you know it or not. And just on that last screen, it's probably worth mentioning. There's a few things that are not obvious. One is a folder called monocular an internal package called monocular. That is ultimately the precursor to what artifact hubs API does now. So when you do a Helm search, it's interact that package is still, excuse me, interacting now with artifact hub. But you can also, if I don't know if anyone has ever tried to do this, but you can actually run your own monocular compatible API, which ultimately you can either run your own instance of artifact hub because it's an open source project. Like let's say you have an air gap environment and you want to do something like that, you can do that and you can pass either to the SDK or the CLI a path to the URL to the actual source where you're searching, but that's where all of that is. And it's just name monocular for historic reasons. So it was monocular, then Helm hub and now artifact hub has an API that's compatible with that. This is where the meat potatoes lives. This is where we're gonna be the primary code base of the Helm project. It's gonna contain every single package that you probably have interacted with over time, everything from how we actually download charts, our basic engine of how we're doing templating, how we're going in and linking our charts, how we're interacting with the Kubernetes API and CLI utilities, how we're rendering. And then my favorite, how we're actually performing signing and verification at being the provenance folder. And then scripting is gonna be where our utilities are gonna live. This is I mentioned earlier, how we go ahead and release the software, how we're doing our testing. We have a lot of utilities that are found inside the script folder, basic shell scripts, but as someone as you see, there's me doing the contribution that broke in here a lot going and making sure our tooling is up to date with the latest changes as we continue to evolve the project. And then finally, testing. We need to have good test data. We have a lot of the different utilities. When we spend up, when we do our testing, we have certificates that we have available so we can do testing so we don't have to generate them on the fly and have to deal with all the fun that deals with certificates because they continue to change and evolve over time. We go ahead and we have some tooling here that's gonna allow us to perform some generic testing. And the test coverage is really high. So that's one of the other reasons that a Helm project is very, very stable software. It's not a fast-moving project at this point. It's relied on by, I guess, by everyone in this room, it sounds like, or most people in the room, and a huge percentage of, a huge number, that's a huge part of the Kubernetes community, right? And so what I'm saying is that there are pull requests that are open and sometimes the reason that they stay open is because they don't have tests. So that's another thing that people can help do is not only help to review those, but even help to give suggestions on making sure that any new functionality for pull requests has those tests and helping to run those tests too. We'll think about, when we talk about stable software, Helm is a big project. It's being used by a large community. Think about a small project, you're just getting started. You can go ahead and it's a small boat. You can go ahead and turn it really easily and it's a little dingy. But Helm at this point, like Kubernetes, is a cruise ship. It takes a long time to turn the boat. So it may take time for things to get in, like any large open source project, but every little bit, you gotta start somewhere. It just takes a little longer to turn. A lot of people depend on Helm not breaking. Yeah. So definitely want to make sure that maybe changes. You don't want to ruin everyone's vacation. No, no. We want you to have your weekends, right? Yeah. So just know that this is where that code lives. Win tests are created, all of the data on this here. But I love this flow chart that Andy put together. Yeah, this really talks about if you have a feature, if you have a change into the primary Helm repository, what does that look like? Well, let's walk through that really fast. This is very important. And one thing just so that this is a new slide, but it really is just a flow chart of what we already have in our pull request process. It's basically just visualizing a lot of what we have in our general documentation. So if you want to look at the docs behind this, we have this all outlined as well. And it just starts with, I got a cool idea. I'm going to create that pull request. Go ahead and hit submit. As we mentioned earlier, there's going to be a triage role that we have in the project. They're going to go ahead and review the pull request. And they're going to say, well, how kind of is it? Is it big? It's a small, what kind? They're going to go ahead and usually label it, because there are certain rules that the project has based on labels. Scott, do you want to talk about the different label types and how many reviewers you need to have with certain labels? Oh, god. OK, so I forget the number of lines of code. But basically, we've got a, the Helm project has a bot that assigns sizes to pull requests. So if it's under a certain number of lines of code, it's an extra small. If it's a little bit more, I forget how many, like 30 or 100. Yeah, I don't know if anyone remembers, but it's basically, it's written in our docs. You don't actually have to remember, because we have a bot to do it for you. So which is why I can't remember. Exactly. But basically, like we've got extra small, small, medium, large, extra large. And anything above a, anything above a small requires two, right? It is above a small, is what I think. Anyway, requires two maintainers to sign off on it, to approve it, in order for that to be merged. So what we'll do next is we'll go ahead and we'll, the triage groups will go in and make some reviewers assign to it, because if it's going to be a certain type of pull request, our triage team knows who would probably be more applicable, like if it's registries and OCI, it'd be me. If it's going to be documentation, it's going to be potentially Scott or Carina, by Carina or maybe, so anyone, so then after that, they're going to go ahead and perform the review. Does it look good? Does it not look good? Are there changes that we need to go back to our, to the user saying, you guys should make some changes? There is, okay. Otherwise, let's go ahead and let's, looks good to me. And very important, depending on the type of pull request and how big it is, you have to have agreements from the two core committers, and then our core maintainers, pardon me, and then finally, you have two options. Maybe even though they approved it, you can close and say, you know what, I don't think it's going to be good for the project. It happens. Otherwise, it gets merged. I think it's like, I was going to say, I think it's a good time to mention, okay, if you haven't had your PR looked at, because that's, I know a lot of you, how do you get eyes on your pull request to get it approved? All right, that's usually the big question. So if you want to talk about that really quickly, because we've got five minutes. Sure, yeah, and just to be clear, we're not going over the rest of the actual, like merge life cycle and release life cycle helm, because we're focusing primarily on the triage maintainer role here, which kind of interested if, like how many people in this audience are going to maybe give that a shot and work on that. We do sometimes need to be pinged, because that is the big bottleneck that we keep mentioning is that, there are fewer helm maintainers now than there have been for a while. So, and partly because it is a stable project, it's not a fast-moving project anymore. It also is because some people have moved on to other things. So, when you're actually working on a pull request or helping to review one, one of the things that's really important right now, or that's very helpful anyway, is to bring those up at the helm meetings. We've got a weekly helm dev meeting, and you don't necessarily even have to be there in person, but even just putting them on the agenda, we will make sure to look at those during the meeting. A lot of times all you need to do is ping, we'll talk at the end about how to get in touch with the community, talk to our Slack channel and say, hey, I can't make it, I threw it on the agenda, just make sure you go ahead and talk about it. Here's a quick little overview about it. Yeah, you shouldn't have to, it's not an official part of the process, but because there's only so much time right now for core maintainers to look at these pull requests and not just look at them, but to actually go through all the steps to ensure that what needs to happen happens and before they get merged, we are at this point relying often on people to be a little bit of a squeaky wheel. You shouldn't have to be, you know, you don't have to beg basically, but you just get in the ping. If you want to become a helm maintainer, we all have aspirations. Here are the steps that you need to go through. Our general community member, this is gonna be most of the people here in the audience, you're a general community member. You can then first be a pull request reviewer, because you don't have to be a maintainer or a triage member, you can just say, hey, I went ahead and reviewed it. Anyone can do it. I put it down, I tested it, it was good. Then we then elevate to becoming a triage maintainer. After you go ahead and you perform the action for a while and you like it and you go to edit and the core maintainers really see you're doing a good job, they'll put you up for vote to become a core maintainer. We have a couple recent votes out there right now. So there are people who are becoming core maintainers. And then finally, you can become a core maintainer. I love being a core maintainer. It's one of the things that makes me excited to get up in the morning is to be able to look at the code base and look at my email and look at the flood that I have from all the issues, pull requests and comments that have come in overnight. And then finally, as Karina mentioned, and we have a couple of the higher up governing ones, especially if you spend time in the project, you become then an org maintainer. So finally, how do you get engaged with the community? We have get up, that's gonna be a primary way to get in touch with the community because we're all doing code, we comment in there, we interact, we have a Kubernetes Slack. We are on three different channels. We have the two primary ones we work on is gonna be Helm users and Helm Dev. And then there is a charge one just for me and the legacy purposes. We have a weekly calls Thursday at 1630 UTC. And then finally, we have our mailing list and you can talk to us there. And just like that, I think we're dead on time. Thank you. And please come by the Helm booth. We will look at the code base with you more in depth than we're able to do in this short session. But please do that, if you're interested of course, don't feel in any way shy to ask. And one thing we're gonna start thinking about doing is our Helm maintainers and core contributors are distributed across the world. We had one very, very successful session in New York City last summer where we actually went through this process with you. We're looking at kicking that back off in a number of different cities coming forward. So if you're interested, we're gonna probably have a few meetups. We're probably gonna coordinate with some of the community days in Kubernetes to try to get out in the community. So be able to look out for that so you can learn about that even further after this week here in Amsterdam. So thank you very much for joining us today and looking forward to your contributions.