The Helm project was initiated initially started, roughly, by Deis, Google, and Bitnami. Deis and Google combining packaging technology in the first iteration of the tooling, and Bitnami providing the actual packages and the expertise in packaging. It then evolved that Google devs focused more on providing the testing, and Deis devs primarily drove the development of the tools, with Bitnami devs contributing charts, and related tech, such as the linter.
Microsoft acquired Deis last year. I was involved in a (very) few of the discussion regarding Helm 3 and Helm summit, and it seemed clear to me that Microsoft was providing resources and people to plan and execute the summit. I have to commend Microsoft for their very light touch at the summit. Other companies might have used the summit as an opportunity to push their brand on the community, but this summit was very community focused. It was all about contributors.
You could really see this on Day 2 when our own Miguel (an Emeritus Maintainer of Helm) moderated a panel of the core devs. As you would expect many, but not all, of the core devs were from Deis and currently working for Microsoft. And very active contributors such as Matt Farina (also a core dev) don’t even work at any of the three initial companies that started Helm. Even the conference MC was not a Microsoftee, but rather from Nike, who are apparently heavy users of Helm. I think that this effort to keep the project a real community open source project will be a strong contribution to the success and longevity of the project.
Day 1 was very “backward facing,” dedicated to reviewing the history of the project, but also with a strong focus on presentations from users discussing how they use Helm. It was fun to hear so many Bitnami sponsored projects (monocular, sealed secrets, our charts, etc…) mentioned throughout the day. We see the numbers of users and contributions growing but it was nice to hear how much the community is embracing our contributions.
Day 1 wasn’t just about celebrating Helm, these users brought up problems and challenges. This was important for Day 2, when the conference switched to planning Helm 3.0.
For example, Ubisoft discussed their heavy usage of Helm. They noted that they struggled at times because Helm assumes charts will be deployed “by themselves” so Helm has limited composability. Related, they also said that they find collaborating on deployments is not as well supported by Helm as they would like. For example, one team cannot easily provide a standard implementation of something like networking or logging across all teams. They are looking at ksonnet to see if that can help. They are also looking at monocular to help with visibility.
I also particularly enjoyed the Chart Museum presentation. Chart Museum provides a highly functional chart repo, and the code seems very community friendly.
After lunch on Day 2, the conference switched to working sessions to discuss Helm 3. To set up for this, 2 of the core maintainers set the groundwork by describing requirements for Helm 3.
While I thought the requirements were reasonable, I did feel that they were a little too prescriptive, and limiting. It felt that they were trying very hard to limit the scope of the changes, and therefore limit the project.
However, Brian Grant from Google went on to make a strong case that Helm should be decomposed into a set of unix-like tools rather than one server and one client, and ensure that each of these tools is built in a really “kubernetes way” (my read was that meant using all of the appropriate parts of the current and future kubernetes API).
In my view, this would be a stronger approach to the tooling. I think it would be important to maintain compatibility with existing Helm 2 charts, as that is where the lion’s share of the user effort has gone so far. However, having a set of smaller tools with strictly defined inputs and outputs could keep the community from splintering as different teams adopt different technologies to fit their needs (I’m thinking of things like jsonnet, ksonnet, and kubecfg). Additionally, I think this approach could result in a deeper relationship between the Kubernetes and Helm communities.
I don’t think the Helm project or community is ready to take this leap in version 3.0. It seemed that there was more “low hanging fruit” in improvements that the community is eager to tackle first.
Overall this was a great event. I look forward to the progress we’ll make as a community on Helm 3.0 given the direction that was set and the long term future of Helm as a project with the group that was represented in Portland last week.