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

feat: add support for pushing chart packages to oci #183

Open
dmccaffery opened this issue May 6, 2022 · 15 comments
Open

feat: add support for pushing chart packages to oci #183

dmccaffery opened this issue May 6, 2022 · 15 comments

Comments

@dmccaffery
Copy link

Add a command, such as push similar to upload that pushes chart packages to an oci registry.

cr push <registry-url>

The cr cli can rely on the push api within helm to perform the work.

OCI support has reached general availability as of helm v3.8.1.

@dirien
Copy link

dirien commented Jul 20, 2022

Hi all,

I would like to work on this task as I need this too.

Questions would be for me:

  • Should it be an extra command, like @dmccaffery suggested with cr push ...
  • Or, should it a flag on the existing cr upload command?

Looking forward for you feedback.

@dmccaffery
Copy link
Author

I hacked a solution in this PR: fluxcd-community/helm-charts#94

@dirien
Copy link

dirien commented Jul 20, 2022

yeah @dmccaffery, that looks cool! Thought the same, but want it to be part of cr.

@dmccaffery
Copy link
Author

Me too! 😁

@dirien
Copy link

dirien commented Jul 20, 2022

Do you prefer the cr push command as stated in your initial post?

@monotek
Copy link

monotek commented Sep 17, 2022

Is somebody activly working on this?
We would like to use this in prometehus community (prometheus-community/helm-charts#2454).

@cpanato
Copy link
Member

cpanato commented Sep 19, 2022

I can plan to work on this but if you have time @dirien go for it

i would implement the cr push

@dmccaffery
Copy link
Author

I'm also happy to work on this now that agreement to implement a separate command (push) is there. I will have time this coming weekend. If anyone else wants to tackle it before then, let me know so we don't duplicate effort.

Thanks!

@dirien
Copy link

dirien commented Sep 19, 2022

As @dmccaffery did the initial issue, it's fair that he has the honour to implement it! Let me know if I can help though! ☺️

@PrivatePuffin
Copy link

Would there also likely be an execution speed improvement?

@kingdonb
Copy link

kingdonb commented Oct 7, 2022

What I found digging through the ends of this thread, you can do this today and it's not through cr but doesn't compromise all that much:

https://github.com/fluxcd-community/helm-charts/pull/94/files#diff-87db21a973eed4fef5f32b267aa60fcee5cbdf03c67fafdc2a9b553bb0b15f34
(from: #183 (comment)) bumping this up for visibility a bit

If you are using chart-releaser-action today, and you just want to add OCI (keeping the original index.yaml-based Helm Repository in place) you can add that 'push charts to GHCR' shim, that re-publishes the same chart files on the OCI repo.

I'd like to see the cr push action make some progress as well, but for what I need today this information might help unblock me a bit sooner and get my OCI repos kickstarted 🎉

I think this dual-publish approach should work for most basic uses, but where I think it will have trouble anyone publishing an umbrella chart. Those will need to either make the full switch (new charts, parent and child, umbrella and what goes under it, all published on OCI, with all references in OCI) or publish different charts in either source, else the users may wind up with charts from both sources, or references in the OCI chart that point back to the old helm repository – and they won't get the benefits as they will still end up downloading and parsing index.yaml – from the action interface for chart-releaser-action, does it make any sense to support publishing to both repos? Or would it make sense to gate with a flag (eg. legacy_publish: true or oci_publish: true) and change the flags defaults when the major version for cr bumps?

@Ornias1993 OCI represents all kind of speed improvements, the index.yaml is the bottleneck in Helm's traditional repo and it rears its head when you have hundreds or thousands of releases for as many different charts as your repo hosts, I'm sure that's what you mean.

OCI uses a tag index instead, where the tag is a semver (same as Helm has always used) and tag indexes are just way cheaper to parse than index.yaml with metadata for every release. If you're experiencing speed problems, that is most likely where they came from?

Just coming up to speed on this issue, I'm interested to see it finished too 👍

Large chart hosts like bitnami, etc. have the most to gain from this upgrade, since anyone that automates upgrades with Helm will be downloading their index.yaml again in full, for each chart upgrade in any chart in the whole repo, even if they are caching as efficiently as possible, this index file is a very wasteful process in retrospect (and OCI fixes it!)

My knowledge about the chart-releaser project is a bit lacking, does the chart-releaser handle umbrella charts already?

@kingdonb
Copy link

Follow-on to my last post, it seems there are some simplifications we can make and some of my assumptions were too cautious

Turns out I guess that's not as big of an issue as I imagined, since the dependencies will be packaged together in the OCI artifact, the dependency paths only get invoked when you want to run helm dependency build or helm dep update

Is anybody making progress on this, can we make progress? I was prepared to update the github actions workflow, but I was a bit daunted by the go project underneath (and I could try diving in tomorrow, but if it turned out somebody already has...)

@PrivatePuffin
Copy link

PrivatePuffin commented Oct 13, 2022

There is another issue here, and I think that might also hit prometheus-community @kingdonb
If you release your containers on OCI, I don't think you can also release your helm chart on the same OCI using the same name as well...

@kingdonb
Copy link

kingdonb commented Oct 13, 2022

@Ornias1993 That's true-ish... there is a media type on each image layer, there are configurations which you can use to bundle image layers of different types, but a straight helm push into the same image repo as docker build+push is inadvisable. I'm more familiar with this issue from the Flux side, where it's flux push and the media type is configurable.

If you want to release your charts as OCI images, I recommend following the pattern that you see here:

https://github.com/stefanprodan?tab=packages&repo_name=podinfo

Create a repo of the same name, and push app images there (in this case podinfo)

Then, in your organization (or user) create an image repo with charts/podinfo for example. You can create these arbitrary structures on GHCR without creating a corresponding charts git repository, by doing helm push or flux push on-demand, and associate the new OCI image storage repo with the Git repository whose actions to push from via GitHub Actions permissions UI. (This is under-documented, but we should ideally not document all this for GitHub, they should have docs to support this... I haven't found them yet.) Anyway, this approach works well for organizations with many charts, and then the main problem is to ensure all the dependencies also adopt OCI, which may require some string substitution or maybe not... haven't tested it all yet from end-to-end.

I plan to try re-publishing Hephy Workflow as OCI charts in a day or two and we'll see how it goes there.

Pushing a mix of image types to the same repo is inadvisable because you can no longer take advantage of basic semver tags and pattern matching to decide which tag is the latest in your series, you need a way to distinguish between tags of the different types (and scanning the images to read their metadata is expensive and does not scale to thousands of tags, as Flux project knows from our history and experience...)

@jkroepke
Copy link

jkroepke commented Dec 7, 2023

We are using OCI push for months now and it just works great.

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

7 participants