 Hi, welcome to Taking the Helm Becoming a Maintainer. I am Matt Butcher. I'm one of the original founders of the Helm project. Hi, I'm Matt Farina. I'm one of the other mats who helps maintain the Helm project. Hi, I'm Bridget Kremhout. I'm one of the non-mats who helps maintain the Helm project. And I am excited today since we are here to grow our maintainer community to welcome our newest guest. Hi, I'm Karina Angel and I'm interested in becoming a Helm maintainer. For any kind of project before you sign on to be a maintainer of it, you probably want to know what it is. So let's get a quick overview, a quick getting started. Butcher, tell us a short story. Might as well blame the person who started it. Yeah, so Helm was originally conceived of as a package manager for Kubernetes. And we started in I think around 2015. So it's coming up on its sixth anniversary here soon. And the idea was to make it provide a way that made it easy to get started with Kubernetes by installing packages off the shelf. And then as you got comfortable with that particular workflow, we wanted to make it easy for you to be able to compose your own packages. So packages and Helm are called charts. Chart is a collection of templates, templated YAML files that are just Kubernetes YAML files as well as some values and some documentation and some metadata. And so we are now in the middle of the Helm 3 development life cycle. So this is our third major release. We're pretty happy with the way this particular release has been going. And we imagined it'll still be around for a while because it's working out quite well. And then over time we built sort of a robust community around Helm, the particular piece of software. So we will talk a little bit in this session about the community, which means the group of people who are all collectively working on it, whether that's filing issues or opening PRs or even doing maintainer things like reviewing code and signing off on security things. And here and there we'll talk about charts repos and GitHub actions and other tooling that has come around over the last six years of our development. Yeah, absolutely. So I want to turn to Farina and say, hey, there's Helm Helm, sure, but there's a lot more to Helm than just Helm Helm. I think you've been involved in a lot of the work around Helm. Can you give us some lay of the land there? Yes. So Helm was originally started. We had the package manager, but you end up needing and desiring more than that. And over time, more sub projects and documentation and things have come to life from the Helm community, from the Helm project to support those who are creating packages and working with Helm. And so if you go over to the Helm org on GitHub, you'll see quite a few repos and they do various things. These days, we have tools for performing things like testing and to help you test your charts. We have GitHub actions. We have just a number of tools there and contributing to the Helm project can be contributing to any of those things. And it doesn't all have to be code either. All of these projects have documentation and we have a documentation site and even translations of the documentation site. And so there's lots of opportunity to contribute from code to various toolings around the primary things to docs. And so there's a lot that people can get involved in now. When as perhaps a new user slash interested in contributing slash interested in maintaining Helm, when you take a look at this, Karina, what do you immediately have questions about? Or what do you immediately say, Oh, that looks like it's interesting. Like what stands out to you when you start looking at this project? Well, the first things that stand out are what are the easiest issues to get involved in, right? Just to figure out what the project is and how it's maintained and the layout of the repos. And then also the examples, right? That's really interesting for us to look at. Also the documentation, going through the documentation and running through some examples and seeing how it works on, you know, my own system or other systems that I have set up. So that's also another way to kind of dive in and see what's going on or maybe how to get involved with maintaining the project. Just kind of at the ground floor. I know one of the things that's come up when we talked about this before was like, even how does the, how does Helm work with CICD? You asked about using charts and pipelines. And I'll, I'll throw it to Farina say, tell us what's going on there. So the Helm project we have, it depends on what you're talking about with pipelines, right? Because there's so many CI systems out there. And on the Helm project, because so much development is happening on GitHub, especially for those of us who work on the Helm project, these days we've got some tools that can help you in all those CI systems. And some of it that can help you directly with GitHub actions. So for example, if in your pipeline, you want to test a chart and you want to use Helm and you want to test these things, we have a tool called chart testing, abbreviated CT. And so if you go to github.com slash Helm slash chart testing, you can find a chart testing tool. And this goes above and beyond anything you'll find in the core Helm, you know, client, as far as linting and providing test functionality, it builds on that to give you more. And so for example, from that, you can take a chart with multiple different configurations passed in. And you can run that in say maybe a kind cluster running right inside of your CI system. And it provides a simple way to do that. And that's one of the ways to get started in your workflows. And then if you wanted to say use that in a GitHub action, right, instead of having to write your own action, we provide an action for that that you can just take on and start using. And I would like to piggyback on that one and say, you know, recently, a developer friend of mine was trying to build something new for testing Helm charts and stumbled across the GitHub actions and said, you know, you need to tell more people about this. This was great. I could have spent days or weeks even setting up these actions. And the team that built the actions for us is the team that has managed the chart repository for years now. And when you talk about expertly crafted code, this stuff has just been phenomenal for getting started very quickly. So if you're in one of those people who would like to start working on some GitHub actions to get your workflows to get your charts tested and some workflows set down, highly, highly recommend the work by that team, it'll get you a long way very, very fast. What I'm really interested in also are the best practices around CI CD and Helm charts. And is that an area where the documentation within the GitHub repo, does it cover that? I think the best practices around that are probably lacking in our documentation. You know, one of the things that the Kubernetes and cloud native and Helm communities have done really well is take a certain amount of that knowledge and it's passed around tribally, word of mouth, experience, being handed around person to person. And it's not documented in easy to consume ways. And so as we've grown to many more people and many more parts of the world, it's harder to spread that knowledge that way. And so this is actually a perfect opportunity when somebody gains that knowledge to come add it to the Helm documentation to help a lot more people. That's the kind of contribution that we could really use. And that I think a lot of people would appreciate. A contribution we don't even know to ask for. But I'm interested, Butcher, if you want to give us some insight into when you were first coming up with Helm versus the kind of questions people are asking now, what have you seen in the evolution of what people are trying to do with package management? I think that when Helm first started, Kubernetes was so young that the people attracted to Helm were what you would call like the avant-garde of the Kubernetes world, right? They were all out there trying things they didn't care if yesterday's code didn't compile today as long as you got it compiling again in the next 15 minutes. Everything was just moving at a very, very fast pace. And the velocity was great, very invigorating for a long time. But you started to see transitions as Kubernetes stabilized and as people took it from something they were working on as a side project to their main project to something in production, Helm likewise had to change and go from moving fast and breaking things to being stable. And in some ways, the pressure on us I think has been a little bit higher than many of the other ecosystem projects because Helm ends up getting used to manage multiple versions of Kubernetes and multiple instances of all these service meshes and things like that. And so there's a sense in which if Helm breaks, people lose their ability to effectively manage their other systems. So you get this kind of cascading effect in other words, which is part of the reason why we have become very, very risk averse as far as taking PRs and why things sit in our issue queue and get reviewed lots and lots of times and why the security team will flag issues and say we've got to review this before we merge it because we're very aware at this point that if we do things wrong, we cost big enterprises and small businesses and everybody in between frustration, downtime and things like that. So really our culture has evolved from being very much a cutting edge, trying all these new things very, very rapidly to one that's very slow and methodical. Some of the new processes like the hip process and our longer review processes and our biannual security reviews are all processes that feed into that long-term stability. Karina, you've been coming to and participating in the Helm community calls. Can you give us from your perspective, not necessarily having authored a hip yet, what is even going on there? What does it look like from the perspective of someone who didn't design the process? Coming in, it was first had to figure out that the process did change. And I know that was communicated and I miss that communication. And so, and then finding the hip process and it's great that it's documented. It's on the repo, but then from there when you create the hip, what is the process going through? Also, when should you write the hip, as Matt was just saying, when should you write the hip versus just writing an extension? Should it be in core Helm or should it be an extension? So those are some of the other questions. So with Helm, Helm's a core package manager. And there's lots of different tools you might want to integrate with, whether it's different object storage systems or there's just different systems you want to tie things to. Or you've got unique processes that you want to try to have that are maybe for a subset of Helm users. If all of that were put into Helm for all of these different variations, you'd end up with a giant monolithic application. And that would be a lot of work for maintainers to support. And trying to make all of that work together is probably going to end up with a lot of spaghetti code too, that's difficult to maintain. And so it leads to just something that's hard to maintain. And we don't want to do all of that, just like you'll see with Kubernetes now, all of these controllers and extensions and direction people want to go in, they're not part of core Kubernetes, they're part of the ecosystem. And Kubernetes is very focused on stability in its API and what it offers, but it gives you the ability to extend it. And the things really have to show themselves to be useful to a mass majority of people to get in now. And I think Helm is kind of that same way. If it's a core Helm, core package management thing for those people who want to run their workloads, then that's a great thing to have in there. But if it's going to be something outside of that, or maybe more of a niche feature in use case, then that's the perfect place for an extension, if it's below Helm or a tool that sits above Helm that tries to do this. So Helm's a package manager. And if you want to get into configuration management, that might be a place for Helm file or something else, just like you'd have Terraform and Chef. And that would deploy your app packages or you know, your Debian packages, things like that. There's this nice separation there, right? It does that thing. We try to have Helm do it well, while enabling things on top of and below it to flourish. I think some of the most contentious issues have been the ones where people say, but I want Helm to be a floor wax and a dessert topping. Why can't Helm do all of the everything? I love Helm. I only want to live in Helm. And you're like, that's going to make Helm un-maintainable for everyone else. And so I think this is a good segue to how does Helm, the project, even make those decisions? So Dr. Butcher, do you want to give us some insight into if, say, Corina would like to rule all things in the Helm universe? What does that pathway look like? Yeah. And it's a little bit of a multi-layered thing, right? We do have a guiding sort of mission statement more or less about Helm, that Helm is the package manager for Kubernetes. So if it falls outside of general package management, then it's unlikely that it's going to make it inside, in general. So there's a certain sense in which people will open a PR to add the floor wax piece. And we say, sorry, Helm is already a dessert topping. And that's all it's going to be. But so there's some things like that that we just use as set guidelines and just kind of draw the line anytime there. But then that's a pretty big problem space that is still left open in there, right? Obviously. And so from there, figuring out where this feature kind of thing might fall, you know, the first one is, is it a bug fixer? Is it a feature? And if it falls into the bug fix thing, then largely all you have to convince somebody is that they should either fix the code or you should fix the code and they should review the code. Second one, by the way, is far preferred by us. But if it's a feature, then typically that's at the point at which you're heading into the space of writing a Helm improvement proposal, a hip. The caveat for that is if you're not sure where your kind of thing falls in that spectrum or if it is really a package manager feature or not, you might not want to dive in and write a five page hip or a three page hip or whatever. And that's why we have things like the Helm developers call, which is a great place to kind of drop in and get to ask in real time. Or, you know, the Helm developer Slack is another good place to ask in Kubernetes, sorry, Kubernetes Slack, Helm dev channel is what I am trying to say there. And then the third option would be to open an issue saying, hey, I'm thinking of this feature. Is this the right kind of feature to go in Helm core and should I write a hip or is this something that's just out of scope or would be better as a Helm plugin or something like that? But any of those three ways will help you get an answer. And of course, your mileage may vary as to which one you get an answer quickest on. You know, you might think that while people will hang around in Slack and answer within minutes, sometimes it happens, sometimes it doesn't. So really is I would urge you to opt for kind of the one that makes you feel the most comfortable of those three, if you're not sure. And then from that point onward, most of the time you're going to be writing a hip. And that's basically a document like I think it's modeled after Python improvement proposals, which were PIPs, the same kind of idea. You walk through that and explain what you want to do and then you then maintainers have a chance to give you feedback before you actually start writing code and it gets really frustrating to have to make those changes. I think maybe we should also clarify that if you want to get a small change into Helm, you don't have to write a proposal first. It's more that if you want to do something that is a significant departure from what is already happening in Helm and might have breaking changes, you probably don't want to spend a ton of time writing some code in order to hear that it's not in any way going to be merged for the next six months minimum. Farina, do you want to kind of talk a little bit about, you know, forward-looking statements, roadmap-y type stuff? Is Helm v4 five minutes away? Can people have their breaking changes merged real soon now? What's your thinking there? So this kind of goes along with how we approach longevity and stability. Lots of things are changing in the cloud-native ecosystem and we're kind of slow to change to bring a point of stability in there. And so Helm v4, which is when we can break when we break major APIs, when we just start changing things in ways that aren't backwards compatible for CI scripts and other things, that's a little ways off. We have just started to have the conversations about, hey, should we start talking about a version four rather than being in-depth on it? And so that's probably a year or two away before v4 is released and we're not quite writing to it yet. Butcher, do you want to give us a little bit of a vision about where the project is going and your wish list for, you know, a wish list item at least of where somebody should get involved? The Helm v3 lifecycle, like I said before, is about midway through. The big items still left in Helm v3 are a lot of these efforts to just sort of solidify and fix little things here and there to make sure everything is aligned well and hopefully to move the OCI registry stuff from experimental and be able to remove that experimental flag and have that in production. So those are two things I'd really like as far as the Helm-Helm codebase itself goes. In sort of like the bigger scheme of things, we have a couple of big challenges that we're trying to tackle as a community. One is translations for the documentation. Thanks to Matt Farina. In fact, we really got that kick started last year, but we still need to keep things moving on that. We actually need to do a little bit of a pass over the core documentation just because documentation tends to get stagnant over time. And, you know, here and there, like we'll stumble across paragraph and say, oh, this still refers to Helm-2 and somehow it slipped through the cracks and nobody's found that and fixed that yet. And then the third one is we really need to get stronger in the core maintainership of Helm. What's happened is Helm being a six-year-old project and an open source project. It means that naturally people tend to cycle through. People work on this for a while as their day job and then, you know, for a little while on nights and weekends, and then they have other obligations that take over it. New people come in. They're excited about it and bring new energy, new ideas, and new passion for the community. And we like to have those people join because it helps a lot. We're kind of mid-cycle right now where we've seen a few people drop off because, you know, acquisitions or new jobs or family changes have made it necessary for them to step out. And we're always grateful for that. That's why we have that emeritus maintainer role. But we also want to be very respectful of people and try not to burn them out. So in this next year, that's another thing we've been trying to focus on for the year 2021, in fact, has been to bring in some new core maintainers and help redivvy out the responsibilities so that we can, you know, be a little more diligent on the hip process, for example, instead of trying to do that after going through and triaging all the issue queue and reviewing PRs and things like that when you're already burned out and don't want to do anything anymore. So those are kind of the three, I guess that's four now, four big things that would be on my wish list. On my wish list is again, yeah, bringing in more maintainers and having just folks who are more active in the project because I think that's going to also spur on more innovation around Helm. And so I think having more people involved will make it the project stronger so that we can have a better Helm version four than we would have with what we have now. And so that's kind of I see the next steps. We're going to have some more features come in and we'll grow the maintainership and then that will spur on here is how the cloud native ecosystems changing. Here's how people are using things a little bit different. Here's some lessons learned about Helm along the way. And as we roll into hopefully something like 2022, we'll be able to start really going after a Helm version four with some great and useful inspiration. And I will add to that that I want to keep improving the documentation, but also improve the workload distribution, get more people reviewing issues, get more people testing PRs, improve the tooling around that to make it easier for people to continue to bring their ideas in and also just frankly, their energy and their time and their desire to improve it. Because I think that's that's how we're going to get better is more community involvement. We have lots of things that we want. And we're looking to you and saying, I think you may be the future. All right, tell us about the future. Well, of course, when I hear the word innovation, right, that's exciting. So how are you looking to get feedback? And you did mention experimentation and, you know, brainstorming. And those all sound like key words, ideas, how to get involved in the exciting aspect of Helm. So maybe if one of you could talk more about how to engage there, where should people bring their brainstorming, their ideas, their energy and their engagement and actually say get those chairs merged? I am going to assume that when given all the stuff we just talked about stability that what we're really looking at what Farina really has in mind at this point is what are we going to do in Helm for not necessarily what kind of big changes can we make in Helm three? And I mean, our process tends to be about halfway through the development of life cycle of one version, we start to think about the next version. And so it really does make sense to try try out some new ideas on the Helm for side. You know, being the advocate of the hip proposal, you know, I think that's a great place to go and spell out some big ideas, right? Like, you know, it would be great in Helm for is if we tried doing CRD management this way, and laid out, you know, kind of a big proposal for that that we could start talking about. Because that's something that would clearly be solve a big problem, but is also clearly a breaking change with today. Or, you know, we could change the workflow to be a little more like this or this big thing is coming down in Kubernetes and we could take advantage of it by doing that. So, you know, if if you're kind of mode of thinking is doing things that way, that is a great way to do that kind of stuff. Because we have the plug-in system in Helm, and because it's relatively integrated with the rest of the Helm flow of doing things, a lot of times you can also in that pre-Helm for phase, mock out the idea as a plug-in and post that plug-in in a GitHub repo with directions on, hey, grab this, run this command and see what happens. And we're thinking, you know, this could be the big thing that would go in over here in Helm and do that kind of thing. I've recently have been experimenting a little bit about different ways of doing storage and signing and verification and retrieval to make it a little more secure. I'll be doing all that work as a plug-in. And if I can't make it work, you know, I'll throw it away. And if I can, then I can point people to it and say, could we do something like this for Helm 4? Because PRs against Helm 3 to show something in Helm 4 are always kind of a little difficult. And a lot of times by doing this kind of thing in isolation, you can just get really far, really fast because you don't have to integrate with any of those other things that are in there. You can just, you know, show a more pure representation of your idea. So those are two ways I can think of that would really help, you know, transform inner inspiration into something that other people can start a dialogue and start experimenting with. Farina, do you have some other ideas besides those? And even just to bring fresh ideas around it, like you're doing security, I've looked at security a little. I'm also looking into CRD management and different ways to do that. And for example, one of the things that I've been looking into is there a way to store information in annotations in a chart. So just like Kubernetes objects have annotations, Helm charts can have annotations. And then can another tool work with Helm charts, starting with just the library, right? Because Helm itself is a library, and you can import it, and then you can make changes on what you've imported. You can use Go composition and things like that. And then you can use other metadata. And you can try out a new idea. And you can build upon what's there in Helm, and just try and experiment. And it's not going to look like Helm. It'll be something a little different. But it gives you the ability to try something new and then see how it goes. And that's a great way to experiment with an idea to be able to showcase it and say, Hey, is this something for Helm for? And even experiment on things in a way that may be like, Hey, look at this experiment. Maybe it's something that's backwards compatible and can even go into Helm three in a sooner amount of time. I feel like this is a lot of insight into the inner workings of what could appear from the outside to be a project that has it all together and is, you know, top of the game, big CNCF project. But you know what? For just software written by humans, like absolutely everything else. Thank you so much, Karina, for helping us make this, I hope, a little more approachable. Do you have any final thoughts or questions or ideas that you want to make sure that people who are thinking about becoming a maintainer of a project like this, perhaps even this one, any more thoughts for them? How do you integrate with other projects? Since there's if you come in and you want to help with a project like Helm, and you also are involved in other projects, how do you integrate with the other projects? Or what are some of the other, are you involved in SIG apps? Are there other areas in Kubernetes that would be helpful to be involved in while you're also looking to get involved with Helm? The cloud native landscape has so many things going on. There's Kubernetes SIG apps. There is CNCF SIG app delivery. There's quite a number of other CNCF projects going on right now. And if you try to get involved in a lot of these different things, you can fall into things like meeting overload or constantly distraction, or a lot of these places have opportunities to contribute and you might get scatterbrained. And so my philosophy is I would say try to figure out the need you have to solve that thing you're interested in chasing after. Because if you're not really interested in it or you're not motivated to go after that thing, then it's really easy to be distracted or something else. But find that thing you're motivated in and then go after that group and maybe look at the things around the periphery that might help you with that. But there's so much out there right now in cloud native that if you start going it just becomes more and more and more. And so I would argue to try to stay focused in that area that you're interested in. And if you're interested in Helm, figure out how you can contribute to Helm and engage there and maybe get a little into SIG apps or a little into SIG app delivery. But if you do realize you'll get pulled in other directions. And so I think focus is an important thing in the cloud native ecosystem. If you actually want to get into the code and development and those things because there's just so many shiny objects. I like how you're saying talking about focusing. And if we talk more about Helm and getting involved there and focusing on different areas of the project, how so tactically going back to tactically, how do you submit a PR? Where's the best way to go and get involved first as an entry level person? Probably the best place to jump in is to just take a look at the issue queue. We always need help, you know, reproducing things with people adding more information to ones where we can't quite figure out where the problem is there. So if you're just trying to kind of get footing there, that's always good. Picking off bug fixes. A lot of, very recently, a lot of the people who have been invaluable to the community and who are probably under recognized at this point are the people who have gone through the issue queue and said, oh, here's one that's marked good first issue, which is a label we'll often put on things that we think are relatively small entry points, and they'll pick off one of those and they'll submit a PR. And then they'll say, oh, this isn't too bad. And then they'll pick off a slightly bigger one and submit a PR. I would say that we as Helm core maintainers need to get a lot better about publicly recognizing those people more than just LGTMing their PRs because they save so much work and time for the core maintainers. And a lot of times, even the easy ones to pick off are often the ones we won't do because we look at it and go, oh, well, I better take on one that's more significant and more substantial in my few hours of time. So those kinds of things can be huge documentation PRs. I cannot tell you how much we appreciate documentation PRs. When you somebody submit something and says, oh, well, I noticed that, you know, this document in this document, we're out of sync. So I tested it and I found the error in this one. Here's a two line fix or here's a forward fix. That means a ton to us because oftentimes we do not read the document start to finish and notice those mistakes anymore because we're just so deep in it that, you know, we come in laser focused on one thing, do it and we're back out again. So those kinds of things have been just excellent and amazing ways to get started. Even just coming to the developer meeting, listening to what's going on and, you know, tracking that maybe following along and some of the issues and following and adding your contributions there. Those are great ways to start. And I think we as core maintainers, we will commit to starting to get better at recognizing people for their contributions. The community used to be so small that when somebody we didn't know committed a new PR, it was like, oh, yay, somebody we don't know, yay. And now it's just like the stream of information that comes in is so daunting for us that we often don't notice or we notice, you know, a month later that, oh, look, this person contributed six PRs in one month. And I don't even know who this person is. And we will commit to getting better about recognizing people for doing that. Because we know that contributing patches can be a little thankless sometimes. But I hope that gives a good idea of some of the ways you can really kind of get started, whether your passion is more documentation usability, translations, or whether it's diving into nitty gritty details of the code and helping us solve difficult problems. I think it's also important to remember that if somebody takes a little while to review their PR, it doesn't mean that they don't care. It might mean that helm is part of their full time job, but it is not 100% of their full time job. And so they will get to it as soon as they can. But hey, that's why we want to grow the maintainer communities. We have more people out there testing and reviewing and merging those PRs. Well, thank you. I think we're at time and really, really appreciate you all making time to come to our session today. github.com slash helm helm is where the code is github.com slash helm community is sort of the hub for how we organize anything. If you've got questions, feel free, drop in that developer call, drop in the Kubernetes Slack at the helm dev channel or just drop into that issue queue. Thank you once again. And thank you very much, Karina, for joining us today. It has been really insightful. And thank you for being open and honest and sharing a lot of that feedback. As core maintainers, we like the challenge of improving. And we know we've got work to do. So it's been great to hear you come in and not only encourage us, but also present some new challenges for things that we could do better.