harbor: Harbor `2.8.0` deleted Helm Charts, broken release pipelines, removed Chart repository functionality

Just to add my 2 cents: @sspreitzer isnt the only one who is heavily dissatisfied by the process AND the implementation. As it stands the migration process proposed is horrible and mostly not feasible for bigger installs with thousands of charts. There is also exactly no support for interacting with non-OCI charts on Artifacthub, despite MOST charts still not being published as OCI.

edit: just to make clear: im not against removing chartmuseum. Im against doing it such a sloppy way without actually migrating things already present in the registry and also cutting off major parts of the existing ecosystem. IMO the proper way to handle this would have been to block fresh chart uploads in 2.7 and to convert every chart resent at that point into an OCI chart in the same project. AND supporting conversion in sync jobs

We were luckily not affected, since we didn’t use chartmuseum before, but I do think that such a breaking change (including data loss) should have been made way more explicit in the release notes.

(I don’t really care if Harbor uses semantic versioning or not. As long as Harbor doesn’t clearly state to use semantic versioning, it is wrong for any user to blindly assume otherwise. I can think of many well known open source projects that don’t use semantic versioning even though the version number may look as if they did.)

The release notes of 2.8.0 on Github do state the removal of chartmuseum, but I don’t this this is nearly enough to convey the consequences to the end user. For me, as the end user, this reads as some implementation detail that I don’t really need to concern myself with.

I think that the release notes should have mentioned in clear words that this update removes the functionality to store helm charts in the previous format and that it will delete existing charts from the registry without converting them to OCI artifacts.

I read the release notes of every release and I still could have easily been surprised by this change (if we’d happened to store helm charts in harbor), because the release notes only mentioned the removal of some technical component (which happens with almost every release without breakage), but not the consequences.

Edit: That being said: Installing an update without testing it on staging or without at least having some backups ready seems like madness to me anyway.

We are similarly affected and use ArgoCD to manage our clusters (although I caught that 2.8.0 has this change, and only upgraded our pre-production harbor) and I am wondering about the migration steps: https://github.com/goharbor/harbor/wiki/Migrate-helm-chart-to-oci-registry-in-Harbor

10 manual steps for a migration is rather burdensome for admins, especially with many (hundreds) of projects that have charts, and some of the “steps” are actually fairly involved (step 1, for example, is not trivial if you haven’t set up harbor locally before). Was the community involved in deciding how the migration could be handled?

Additionally, Helm charts in OCI storage can collide with docker images of the same name, which makes migration harder. Harbor will represent both correctly, but if the tag collides, the last push wins, and there is no way to pull a chart from OCI storage by digest at the moment with any tools. I also tried to prefix or rename charts to work around the name collision, but you have to open the tgz and edit the Chart’s Chart.yml to change the name that Harbor detects on helm push, which is effectively a breaking change for all consumers of that chart. So if you were using semver semantics for your own charts - every single version needs to be renamed and repushed, and as was noted above, version constraints are unsupported.

Edit:

Included some screenshots to show the tag conflict issues with docker images + Helm Charts of the same identity in a Harbor project:

If your deployment pattern is like ours, and you name Helm Charts + Docker Images w/same name + version tags, you will have collisions. We adopted this pattern because we saw it frequently in the OSS community. I guess this is no longer a first-class pattern and we should name the Helm artifact differently, or prefix it?

I’m considering downgrading to 2.7.x and waiting there for a while We decided to stick to 2.7.2 and are evaluating alternative Helm storage options, so we can communicate to our teams to remove their helm charts from our internal Harbor.