Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
rogerioefonseca opened this issue Dec 16, 2021 · 19 comments

Comments

@rogerioefonseca
Copy link

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
Copy link
Collaborator

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

I see a couple of things like this:


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
Copy link
Collaborator

brianberzins commented Dec 16, 2021

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
Copy link
Author

rogerioefonseca commented Dec 17, 2021

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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

rogerioefonseca commented Dec 19, 2021

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
Copy link
Author

Ping!
Happy new year!!

@brianberzins
Copy link
Collaborator

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
Copy link
Author

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
Copy link
Collaborator

brianberzins commented Jan 4, 2022

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:

@rogerioefonseca
Copy link
Author

rogerioefonseca commented Jan 10, 2022

No it is not that one.
The chart version should match the TAG version -

@rogerioefonseca
Copy link
Author

Ping...

@brianberzins
Copy link
Collaborator

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
Copy link
Author

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

@brianberzins
Copy link
Collaborator

@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
Copy link
Collaborator

@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
Copy link
Author

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
Copy link
Collaborator

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
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants