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

Flux oci support 9: fix helm repository cache out-of-sync when remote contents changes #5222

Merged
merged 9 commits into from Aug 22, 2022

Conversation

gfichtenholt
Copy link
Contributor

@gfichtenholt gfichtenholt commented Aug 19, 2022

see #5212 (comment) for description of the problem and the fix

Also renamed cache funcs for simplicity and to save time on typing:

  • GetForOne => Get
  • GetForMultiple => GetMultiple
  • fetchForOne => fetch
  • fetchForMultiple => fetchMultiple

All tests (integration+unit) passing

@netlify
Copy link

netlify bot commented Aug 19, 2022

Deploy Preview for kubeapps-dev canceled.

Built without sensitive environment variables

Name Link
🔨 Latest commit 553de28
🔍 Latest deploy log https://app.netlify.com/sites/kubeapps-dev/deploys/6303a0a7649453000925e7fd

@gfichtenholt gfichtenholt self-assigned this Aug 19, 2022
@gfichtenholt gfichtenholt linked an issue Aug 19, 2022 that may be closed by this pull request
Copy link
Contributor

@antgamdia antgamdia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, thanks for adding this solution. Way better than just getting rid of the cache!
I just have a question (see above), but +1 anyway. Thanks!

func (s *repoEventSink) onAddOciRepo(repo sourcev1.HelmRepository) ([]byte, bool, error) {
log.Infof("+onAddOciRepo(%s)", common.PrettyPrint(repo))
defer log.Info("-onAddOciRepo")

// I am disabling repo cache due to
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you or is it just a leftover comment? It seems you are still using the cacheEntryValue, no?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just left over comment. WIll fix


if s.chartCache != nil {
fn := downloadOCIChartFn(ociChartRepo)
if err = s.chartCache.SyncCharts(charts, fn); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this is still syncing by just adding any new versions, no? I mean, in the event of a chart deprecation, the package won't get removed from the cache, no?
If so, wouldn't the upstream checksum always differ from the cached one which may lead to a permanent cache-miss state?

Not sure, just asking, though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this is still syncing by just adding any new versions, no? I mean, in the event of a chart deprecation, the package won't get removed from the cache, no?

correct. BTW, related #4115 is still open. Just didn't get to it yet

If so, wouldn't the upstream checksum always differ from the cached one which may lead to a permanent cache-miss state?

Not sure, just asking, though.

I don't think so. The checksum is computed by my code without having to look what charts are in the local chart cache and is stored separately from the cached charts. It only looks at the charts and corresponding tags on the remote. If different from what is store in the cache, the new checksum is stored in the entry again

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, ok, ok, got it. If we aren't looking at the charts in the local cache for computing it, then it doesn't seem an issue. Thanks for the clarification!

@@ -59,7 +59,7 @@ function pushChartToMyGitHubRegistry() {
-H "Accept: application/vnd.github+json" \
/user/packages/container/helm-charts%2Fpodinfo/versions | jq -rc '.[].metadata.container.tags[]')
echo
echo Remote Repository aka Package [${L_YELLOW}$GITHUB_OCI_REGISTRY_URL/podinfo${NC}] / All Versions
echo -e Remote Repository aka Package [${L_YELLOW}$GITHUB_OCI_REGISTRY_URL/podinfo${NC}] / All Versions
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick: echo -e is not POSIX-compliant (although we are using it a couple of times in the CI and it works). Just for the record, I'm ok with it, thoguh.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fair enough. So be it. The benefits of using it at the moment outweigh this drawback. Makes output so much easier to read by focusing on the keywords that are colored different that the rest of the output. If this becomes an issue, I'll get rid of it

@antgamdia
Copy link
Contributor

The CI fix is now out, once you merge latest main, the CI checks should be passing.
FYI, you can just click on the new "update branch" button in github:
image

@gfichtenholt
Copy link
Contributor Author

Great, thanks for adding this solution. Way better than just getting rid of the cache! I just have a question (see above), but +1 anyway. Thanks!

Thank you for the review

@gfichtenholt gfichtenholt merged commit 42b4aae into vmware-tanzu:main Aug 22, 2022
@gfichtenholt gfichtenholt deleted the flux-oci-support-9 branch August 22, 2022 15:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Support for OCI registries in Flux plugin
3 participants