Split the helm chart into a new repo or Equate the the Helm chart version with the pod-reaper version

[rogerioefonseca]

Hello, I'm configuring the pod-reaper helm chart with Renovate bot, then I figured that the helm chart version is not the same as the pod-reaper code. For that there are 2 strategies that I can see now: 1 - Separate the Helm chart code in a new repo and maintain it there (That would be a better OMHO) 2 - Equate the Helm Chart version to match the pod-reaper version so then I could create a new MR with a real tagging version.

[brianberzins]

I actually don't know much about helm...

I see a couple of things like this: https://github.com/target/pod-reaper/blob/9b4221dc62d437ef21d36ee5046d7e882f3ec97a/chart/pod-reaper/values.yaml#L6 https://github.com/target/pod-reaper/blob/9b4221dc62d437ef21d36ee5046d7e882f3ec97a/chart/pod-reaper/Chart.yaml#L4

Seems like both of those are candidates for matching up with the pod-reaper version correct? Is there a repository where new versions are updated? How is it being used right now?

[brianberzins]

Trying to ask this a different way. With charts also being versioned, are the charts published anywhere (or are they someone pulled directly from github/here)? Trying to see if/when these have been published.

I've got a lot to learn here!

[rogerioefonseca]

Nice, so regarding that, the strategy that is most common to opensource projects is to create a separate repo only for the helm files, create the helm package and add it to the repo as well and then integrate that repo with the CNCF project https://artifacthub.io/. After that we will be able to install the helm charts using only the helm repo add and helm install pod-reaper --version XYZ

I can see those steps ahead.

• [ ] Create a new repo and on that, include only the helm yaml files and needs.
• [ ] Create the new stable helm package with - [ ] Create the structure like mkdir stable && helm package . -d stable/ - [ ] Create the helm package helm package . -d stable/
• [ ] Enable the github pages in the repository properties
• [ ] Create an account in artifacthub.io, create a new repo and integrate that with the GitHub pod-reaper github Page

Let me know if I can help somehow.

[rogerioefonseca]

Hey, I took the liberty to execute the steps above, but I would only use it if you agree, and then I would transfer the ownership to you. https://github.com/rogerioefonseca/pod-reaper-helm https://artifacthub.io/packages/helm/pod-reaper-chart/pod-reaper

[brianberzins]

Only managed to find a bit of time to dig at this...

What's the advantage of having a separate repository for just the chart? Doesn't that mean keeping both in sync? Mostly just trying to understand and I suspect that is in part because of how long I've used the pattern of "just have full kubernetes manifest files live in my application's repository, fully codifying the app, deployment configuration, and pipeline together in the same repo".

[rogerioefonseca]

So that is a nice question and my points are pretty much related to your comment when you mention the "just have full kubernetes manifest files live in my application's repository, fully codifying the app, deployment configuration, and pipeline together in the same repo". :) Helm Charts have its only responsibility and it is more related to Kubernetes rather than your application, having the Helm charts in a separate repo would: Pros:

• Make the repository cleaner easy to read(and it is not everyone that needs or knows how to deal with Helm).
• Helm Charts depend on Helm versions and having it in a reparate repo would make it easier to release/tag it.
• As it is an open-source project it would be easier to have the community contributing to it in a direct way.
• We would be using the pattern that CNCF is using, so it would be kind of a "Certificate of good practice"(https://codefresh.io/docs/docs/new-helm/helm-best-practices/)
• Maybe in the future, we could think of running the pod-reaper in an AWS lambda function or an ECS Cloud formation code as well, and then we would have to increment the folder structure.

Cons:

• If you have to change something that affects the helm you would need to create 2 MR's, one for each repo
• Deal with different pipelines and related resources

[rogerioefonseca]

Ping! Happy new year!!

[brianberzins]

I'm currently leaning towards trying to do it in this repo, but mostly because it means fewer PRs, makes it easier to automate between release of the helm chart and the code. Also because I'm not an owner/admin of the Target organization, so I'd have to have someone else make it (unless I want to do it under my personal space).

[rogerioefonseca]

Yep, fair enough, I still did not understand the fewer PR's that you mentioned since the Helm charts are not really being changed that much. Can you please keep the Helm version the same as the repo? :)

[brianberzins]

Oh, maybe my understanding is wrong... wouldn't I want to update the helm chart to use the latest version of the pod-reaper in the helm chart each time I update the pod-reaper?

I'm mostly thinking about this version number: https://github.com/target/pod-reaper/blob/9b4221dc62d437ef21d36ee5046d7e882f3ec97a/chart/pod-reaper/values.yaml#L6

[rogerioefonseca]

No it is not that one. The chart version should match the TAG version - https://github.com/target/pod-reaper/blob/9b4221dc62d437ef21d36ee5046d7e882f3ec97a/chart/pod-reaper/Chart.yaml#L4

[rogerioefonseca]

Ping...

[brianberzins]

Thanks for the ping. I'm mostly just swamped with work this week. I promise it's still on my to-do list

Is there a date you'd really like to see this by? Or just as ASAP thing?

In either case, honestly appreciate the reminders!

[rogerioefonseca]

haha, for me it would be an ASAP thing, haha. :)

[brianberzins]

@rogerioefonseca Way too much I'm not tracking with helm. Any chance you'd be up for a pair programming session sometime? I think there are a few things needed to make this work that'd be overstepping my bounds as I'm not an admin on this repo. So I'm considering doing this all myself on a git repo (very similar to what you had), but I'd like to know more about expected use cases.

When this is all working properly, what are some examples of commands you want to see working?

[brianberzins]

@slushpupie Do you (or know someone else) know/use helm well/often? Seems like some steps here would be asking for another repo or at least initializing git admin pages/setting up an account on artifacthub.io

Struggling with a back and forth between wanting to keep everything together and breaking it out/letting someone else (even if it's me) own the helm chart.

[rogerioefonseca]

Sure! We can do pair programming and discuss the pros and cons. Let me know if one of these slots works for you:

https://calendly.com/d/cmr-zbp-64k/helm-chart-conversation

Regarding your points: 1 - After having a new repository configured with Github pages and published in artifact.io I would just need to:

helm repo add pod-reaper https://rogerioefonseca.github.io/pod-reaper-helm/charts
helm install pod-reaper

2 - And yes I use Helm often

[brianberzins]

got a This calendar is currently unavailable. Also pinged an admin on the repo to see what they think. Otherwise, I can set it up under my personal space if/until we sort something out.

Sincere apologies, but I've been swamped the last few weeks and I'm still catching up. Still poking at this when I catch a few minutes here and there.

[rogerioefonseca]

Hey there, sorry for the lack of reply! I manage here inside do check the helm version internally, was a little tricky but worked. If you are still opened to, let me know when it would be a good date to discuss this topic, it is still relevant in my opinion. Best