-
Notifications
You must be signed in to change notification settings - Fork 620
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Kustomization status "failed to parse digest: invalid checksum digest format" #3861
Comments
Please update your GitRepository and Kustomization manifests to v1, the checksum format has changed in RC.1 |
@stefanprodan thanks! I changed both to plain Might I have to "clean up" manually some store where these "old style" checksums are stored? |
If you delete the source-controller pod, the checksums should be recalculated, please see if this fixes it. |
Can you share the Status of the GitRepository object? |
The status of the GitRepository (before restarting source-controller):
After restarting source-controller and reconciling GitRepository:
I notice that after restarting the source-controller, a And now, reconciling the Kustomization works, too. Thanks! I'll watch out for the next days if it reappears, but I guess that should have fixed it. |
Upgraded to |
In the upcoming RC.3 release, this should be resolved automatically due to the change from the PR referenced above. Thank you for the report @MartinEmrich. 🙇 |
Describe the bug
A Kustomization referring to a GitRepository with only two CustomResourceDefinition objects, sometimes gets stuck in Status
failed to parse digest: invalid checksum digest format
.Googling this error messages, it appears mostly in the context of (damaged?) container image layers from OCI repositories. But around this Kustomization, there's nothing even close to a PodSpecTemplate, and no containers.
Steps to reproduce
Expected behavior
The Kustomization should stay in status "Applied revision xxxxxxx".
If this error is "real", I would expect an error message leading me to a possible cause/solution.
Screenshots and recordings
No response
OS / Distro
AWS EKS 1.24
Flux version
N/A
Flux check
► checking prerequisites
✔ Kubernetes 1.24.12-eks-ec5523e >=1.20.6-0
► checking controllers
✔ helm-controller: deployment ready
► ghcr.io/fluxcd/helm-controller:v0.32.1
✔ image-automation-controller: deployment ready
► ghcr.io/fluxcd/image-automation-controller:v0.17.1
✔ image-reflector-controller: deployment ready
► ghcr.io/fluxcd/image-reflector-controller:v0.13.2
✔ kustomize-controller: deployment ready
► ghcr.io/fluxcd/kustomize-controller:v1.0.0-rc.1
✔ notification-controller: deployment ready
► ghcr.io/fluxcd/notification-controller:v1.0.0-rc.1
✔ source-controller: deployment ready
► ghcr.io/fluxcd/source-controller:v1.0.0-rc.1
► checking crds
✔ alerts.notification.toolkit.fluxcd.io/v1beta2
✔ buckets.source.toolkit.fluxcd.io/v1beta2
✔ gitrepositories.source.toolkit.fluxcd.io/v1
✔ helmcharts.source.toolkit.fluxcd.io/v1beta2
✔ helmreleases.helm.toolkit.fluxcd.io/v2beta1
✔ helmrepositories.source.toolkit.fluxcd.io/v1beta2
✔ imagepolicies.image.toolkit.fluxcd.io/v1beta1
✔ imagerepositories.image.toolkit.fluxcd.io/v1beta1
✔ imageupdateautomations.image.toolkit.fluxcd.io/v1beta1
✔ kustomizations.kustomize.toolkit.fluxcd.io/v1
✔ ocirepositories.source.toolkit.fluxcd.io/v1beta2
✔ providers.notification.toolkit.fluxcd.io/v1beta2
✔ receivers.notification.toolkit.fluxcd.io/v1
✔ all checks passed
Git provider
No response
Container Registry provider
No response
Additional context
Server-side versions:
Code of Conduct
The text was updated successfully, but these errors were encountered: