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

status.lastUnpacked is being updated on every pull attempt #389

Closed
m1kola opened this issue Sep 10, 2024 · 4 comments · Fixed by #397
Closed

status.lastUnpacked is being updated on every pull attempt #389

m1kola opened this issue Sep 10, 2024 · 4 comments · Fixed by #397
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@m1kola
Copy link
Member

m1kola commented Sep 10, 2024

It seems like .status.lastUnpacked is being updated on every poll attempt even when the content of the catalog hasn't changed.

Steps to reproduce

  1. Create a catalog with frequent poll interval:
    apiVersion: olm.operatorframework.io/v1alpha1
    kind: ClusterCatalog
    metadata:
      name: operatorhubio
    spec:
      source:
        type: image
        image:
          ref: quay.io/operatorhubio/catalog:latest
          pollInterval: 5s
  2. Watch the status fields:
    kubectl get clustercatalog operatorhubio -o json -w | jq '{".status.lastUnpacked": .status.lastUnpacked, ".status.resolvedSource.image.lastUnpacked": .status.resolvedSource.image.lastUnpacked, ".status.resolvedSource.image.lastPollAttempt": .status.resolvedSource.image.lastPollAttempt}'

Result

{
  ".status.lastUnpacked": "2024-09-10T13:03:18Z",
  ".status.resolvedSource.image.lastUnpacked": "2024-09-10T13:03:18Z",
  ".status.resolvedSource.image.lastPollAttempt": "2024-09-10T13:03:18Z"
}
{
  ".status.lastUnpacked": "2024-09-10T13:03:24Z",
  ".status.resolvedSource.image.lastUnpacked": "2024-09-10T13:03:24Z",
  ".status.resolvedSource.image.lastPollAttempt": "2024-09-10T13:03:24Z"
}

Expected result

.status.lastUnpacked and .status.resolvedSource.image.lastUnpacked should stay the same as long as the content of the catalog is the same.

@m1kola m1kola added the kind/bug Categorizes issue or PR as related to a bug. label Sep 10, 2024
@m1kola
Copy link
Member Author

m1kola commented Sep 10, 2024

I think the issue is that we set LastUnpacked in Result struct to "now" here on line 86:

digest, isDigest := imgRef.(name.Digest)
if isDigest {
hexVal := strings.TrimPrefix(digest.DigestStr(), "sha256:")
unpackPath := filepath.Join(i.BaseCachePath, catalog.Name, hexVal)
if stat, err := os.Stat(unpackPath); err == nil && stat.IsDir() {
l.V(1).Info("found image in filesystem cache", "digest", hexVal)
return unpackedResult(os.DirFS(unpackPath), catalog, digest.String(), metav1.Time{Time: time.Now()}), nil
}
}

Despite the fact that we just return the content we already had. We probably should set it to "now" here only here.

@joelanford
Copy link
Member

Possibly related: #379

@m1kola
Copy link
Member Author

m1kola commented Sep 11, 2024

I don't think #379 is related: so far it does not seem to fix this bug.


In additional to my my previous I suspect that ImageRegistry's Unpack is not working as expected.

From the unit tests it seems like the expected behaviour is that when we the spec has an image such as quay.io/operatorhubio/catalog:latest (with a tag) we will be resolving a tag into a digest and checking if we already have a cache for that digest here. However we only seem to parse image reference and attempt to type cast into name.Digest without actually resolving image tag - this will always return isDigest==false for image refs with tags. So we will never be hitting this code when working with image refs with tags.

We have test cases for both digest and tag image refs, but the test is very complex with a lot of parameters. I suspect that something went wrong with the test because it shows green.

@m1kola
Copy link
Member Author

m1kola commented Sep 11, 2024

Ok, the above seems to be a separate bug. Reported: #392

This probably needs to be fixed before this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants