Deleting a chart that has a version number in its name via the API causes no removal from index

[garnold54]

It seems that deleting a chart that has a version number in its name via the API does not delete the entry from the index. The package is deleted from the file system. Seems similar to #22

With a chart named mychart:

curl -X POST -k --data-binary "@mychart-0.1.1.tgz" localhost:8080/api/charts
{"saved":true}

curl localhost:8080/api/charts
{"mychart":[{"name":"mychart","version":"0.1.1","description":"my chart beta","apiVersion":"v1","appVersion":"1.0.0 BETA","urls":["charts/mychart-0.1.1.tgz"],"created":"2019-03-29T16:45:58Z","digest":"be1e1edef408420a3c004b2c88bd9c02ef3f34b6d346fe7a4a264297909da978"}]}

curl -X DELETE localhost:8080/api/charts/mychart/0.1.1
{"deleted":true}

curl localhost:8080/api/charts
{}

With a chart named mychart-1.0

curl -X POST -k --data-binary "@mychart-1.0-0.1.1.tgz" localhost:8080/api/charts
{"saved":true}

curl localhost:8080/api/charts
{"mychart-1.0":[{"name":"mychart-1.0","version":"0.1.1","description":"My Chart","apiVersion":"v1","appVersion":"1.0 BETA","urls":["charts/mychart-1.0-0.1.1.tgz"],"created":"2019-03-29T16:52:01Z","digest":"3a64e207bbc0c69e2027f7795b79c9feb5b64aa18c19e5730f95a09ae0cada57"}]}

curl -X DELETE localhost:8080/api/charts/mychart-1.0/0.1.1
{"deleted":true}

curl localhost:8080/api/charts
{"mychart-1.0":[{"name":"mychart-1.0","version":"0.1.1","description":"My Chart","apiVersion":"v1","appVersion":"1.0 BETA","urls":["charts/mychart-1.0-0.1.1.tgz"],"created":"2019-03-29T16:52:01Z","digest":"3a64e207bbc0c69e2027f7795b79c9feb5b64aa18c19e5730f95a09ae0cada57"}]}

Cheers,
Grant

[jdolitsky]

@garnold54 thanks for opening. this may be a tough one to sort out.

Do you mind elaborating on why you put the version in chart name vs just the version?

[garnold54]

We want to maintain different versions of our helm chart that correspond to different versions of our app. So for example we may release version 1.0 of our app. We have a helm chart for the app. In my example, the version of the helm chart is 0.1.1 and the version of our app is 1.0. So we want the name of the chart to be mychart-1.0 and the version of the chart is 0.1.1. Now we start working on version 2.0 of our app, which also needs to be deployed with a helm chart. Our app version 2.0 might need different parameters or changes that don't make sense for our app version 1.0. So we want to maintain two streams of the helm chart, one for version 1.0, and one for version 2.0. So we name them mychart-1.0 and mychart-2.0 Then we can commit fixes to the helm chart for our 1.0 app and bump its helm chart version separate from our app version while also adding new things needed in the helm chart for the 2.0 version of our app separately by naming them in this way.

Hope that makes sense!

[jdolitsky]

@garnold54 i see what youre trying to do. I guess my only suggestion at this point is to use a different naming scheme without any number or period chars, such as "mychart" and "mychart-legacy". Unfortunately due to the naming convention of the tarballs this is pretty difficult to solve for all cases.

If you absolutely need to do this, maybe you can take a look at the method that handles this and see if you can come up with a more elaborate solution: https://github.com/helm/chartmuseum/blob/master/pkg/repo/chart.go#L102

[Cweiping]

@garnold54 Bug already fixed,please see #268

[xiongkun01]

@garnold54 Bug already fixed,please see #268
There are still bugs after the fix，such as version: 0.1.1-58955665. It is inaccurate to find the version by judging whether the first character is a digit.

[leoschet]

I tried deleting a chart using the same curl command described in the issue and although the .tgz file was deleted, the index-cache.yml was not updated. My chart's name has no version

[kobynet]

I tried deleting a chart using the same curl command described in the issue and although the .tgz file was deleted, the index-cache.yml was not updated. My chart's name has no version

Same happens to me, using 0.12 version

[crsantini]

Having the same issue here, my version is something like 1.0.0-rc1

[piyush94]

This issue is happening for me with chart version like 0.1.0-SNAPSHOT-24
Also for 0.1.0-24
Is this versioning scheme incompatible with chartmuseum ?
ChartMuseum version 0.12.0 (build 101e26a)

[scbizu]

@piyush94 hihi , could you provide the whole command you delete your chart ? And It will be helpful if you can open the debug mode , and paste the log from chartmuseum .

[piyush94]

@scbizu I deleted the chart using API
curl -X DELETE http://localhost:8879/api/charts/charts/versiontest/0.1.0-SNAPSHOT-24
I got response code 200, tgz file was also deleted but the index cache was not cleared.

[scbizu]

@piyush94 The DELETE method will not regenerate the index cache and only do delete the backend server chart (the .tgz file) but you can do the other GET /api/:repo/charts request , it will regenerate the index cache for u if the chartmuseum works correctly .

BTW, you can open up the debug mode to see what was really happened with chartmuseum XD

[piyush94]

@scbizu This issue happens when there is a index-cache.yaml file created by chartmuseum when i did helm repo update.
Then if i delete the versions i mentioned above, the tgz file gets deleted but index-cache.yaml is not recreated/refreshed even if send a GET request or do helm repo update

In the logs it says regenerating but entries are still there.

2020-08-04T07:27:48.867-0400    DEBUG   [5] Incoming request: /api/charts/charts        {"reqID": "7fe078b4-60a1-4cfb-a773-5565acf21dbb"}
2020-08-04T07:27:48.867-0400    DEBUG   [5] Entry found in cache store  {"repo": "charts", "reqID": "7fe078b4-60a1-4cfb-a773-5565acf21dbb"}
2020-08-04T07:27:48.867-0400    DEBUG   [5] Fetching chart list from storage    {"repo": "charts", "reqID": "7fe078b4-60a1-4cfb-a773-5565acf21dbb"}
2020-08-04T07:27:48.867-0400    DEBUG   [5] Change detected between cache and storage   {"repo": "charts", "reqID": "7fe078b4-60a1-4cfb-a773-5565acf21dbb"}
2020-08-04T07:27:48.867-0400    DEBUG   [5] Regenerating index.yaml     {"repo": "charts", "reqID": "7fe078b4-60a1-4cfb-a773-5565acf21dbb"}
2020-08-04T07:27:48.867-0400    DEBUG   [5] Removing chart from index   {"repo": "charts", "name": "semvertest-0.1.0-SNAPSHOT", "version": "24", "reqID": "7fe078b4-60a1-4cfb-a773-5565acf21dbb"}
2020-08-04T07:27:48.867-0400    DEBUG   [5] index.yaml regenerated      {"repo": "charts", "reqID": "7fe078b4-60a1-4cfb-a773-5565acf21dbb"}
2020-08-04T07:27:48.867-0400    DEBUG   [5] Entry saved in cache store  {"repo": "charts", "reqID": "7fe078b4-60a1-4cfb-a773-5565acf21dbb"}

As you can see parsing is not correct here,
"name": "semvertest-0.1.0-SNAPSHOT", "version": "24"
version is not 24, it is 0.1.0-SNAPSHOT-24
and name is semvertest

[scbizu]

@piyush94 Could you provide me your Chart.yaml content details ?

[kobynet]

@scbizu We are facing the same issue as @piyush94 , also with this kind of version: 1.0-SNAPSHOT+some-meta-data which is a valid semver 2.0 version.

[scbizu]

@kobynet could you check your Chart.yaml if the version is also the valid semver version (and the same as your chart filename) or not ？

[kobynet]

@scbizu our chart file consists of
<chart name>-<chart version> where chart name is words delimited with dash('-') and chart version is of the form 1.0-SNAPSHOT+<metadata> where metadata can include dashes('-') or dots('.') and regular strings.

Our chart version in Chart.yaml is exactly the same as shown in chartmuseum, which is for example 1.0-SNAPSHOT+PR-102
and example for the full chart (name+version)
my-chart-1.0-SNAPSHOT+PR-102

[scbizu]

@kobynet It seems that your example chart version is not the valid semver2 version (at least for the helm used semver2 Go package). See https://goplay.space/#vKdQ4mpQBQw

[kobynet]

@scbizu That is because you put in the version field, the whole chart including it's name, if you put only
version := "1.0-SNAPSHOT+PR-102"
it will work fine.

Just for the sake of solving this problem, i've also tried with "1.0.0-SNAPSHOT+PR-102" and got the same result, file was deleted, but index wasnt updated after GET requests.

[scbizu]

@kobynet Sorry for my bad reading , but I think I got the point , as #22 mentioned , the semver2 version like 1.0-SNAPSHOT+PR will work as expected. I write some tests to check if 1.0-SNAPSHOT+PR-102 will work out the right version through emptyChartVersionFromPackageFilename function , but it failed with the incorrect version 102 .

Then I look a little deeper into the codebase , and I find that the current solution with only filename but no content Chart.yaml do not actually support the even valid semver2 version like yours 1.0.0-SNAPSHOT+PR-102. It only gets the last numbers series after - , for example , the version like 1.0.0-SNAPSHOT+PR-XXX(replace the number with string characters) will be well parsed.

I will work on a PR these days and thanks for your detail report XD.

(BTW , due to the diff between stored chart and cached chart , stored chart is deleted and cached chart is still there , then the stored chart content is empty , and the cached chart will be never deleted)

[kobynet]

@scbizu Thanks a lot for your comments and support!

[guykanyvision]

Is there any workaround? i can't get the chart deleted

[kobynet]

Is there any workaround? i can't get the chart deleted

@guykanyvision It's a work-in-progress, see #362

[hoozecn]

Is there any workaround? i can't get the chart deleted

Here is what I did:

1. delete chart

curl -XDELETE 'http://xxx:xxx@charts:8080/api/charts/chart-name/1.0.0

2. delete the cache file in chartmuseum: /charts/index-cache.yaml
3. restart the chartmuseum process

[jdolitsky]

@hoozecn thanks for sharing that.

For users seeing this issue - you can disable index-cache.yaml with --disable-statefiles / DISABLE_STATEFILES=1