🌱 fix TestClusterExtensionInstallReResolvesWhenNewCataloge2e test #1008
Conversation
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1008 +/- ##
=======================================
Coverage 77.19% 77.19%
=======================================
Files 17 17
Lines 1206 1206
=======================================
Hits 931 931
Misses 193 193
Partials 82 82
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
yashoza19
force-pushed
the
issue945
branch
2 times, most recently
from
09ff7f3
to
4065eb1
Compare
test/tools/build-push-e2e-catalog.sh
Outdated
| echo "Illegal number of arguments passed" | ||
| echo "${help}" | ||
| exit 1 | ||
| fi | ||
|
|
||
| namespace=$1 | ||
| tag=$2 | ||
| image=$2 | ||
| tag=$3 |
There was a problem hiding this comment.
Instead of passing an extra tag argument, can we parse the image argument to extract the tag? That would decrease chance of mistakes and copy/pasta errors.
There was a problem hiding this comment.
good call. I will update it.
| func patchTestCatalog(ctx context.Context, name string, newImageRef string) (*catalogd.ClusterCatalog, error) { | ||
| // Fetch the existing ClusterCatalog | ||
| catalog := &catalogd.ClusterCatalog{} | ||
| err := c.Get(ctx, client.ObjectKey{Name: name}, catalog) | ||
| if err != nil { | ||
| return nil, err | ||
| } | ||
|
|
||
| // Update the ImageRef | ||
| catalog.Spec.Source.Image.Ref = newImageRef | ||
|
|
||
| // Patch the ClusterCatalog | ||
| err = c.Update(ctx, catalog) | ||
| if err != nil { | ||
| return nil, err | ||
| } | ||
|
|
||
| return catalog, err | ||
| } |
There was a problem hiding this comment.
I think this is a valid test case (where we patch the spec of a ClusterCatalog), but it does not cover the case I had in mind (and a case I think we need to cover).
What I have in mind here specifically is that we need to prove that the polling behavior alone is enough to trigger an upgrade of a ClusterExtension. Forcing a change by changing the image in the ClusterCatalog spec is a side-effect foils the true intention of the test.
This "polling triggers an upgrade" test is one of the most important features of OLM, so we unfortunately can't "fake" it by touching the spec.
There was a problem hiding this comment.
That was my first approach as well. Unfortunately, I can't find a way to change the latest image tag on a local registry. crane does not allow to change tags on local registries, hence I took this approach. Let me know if you you think this is still a valid test or we can approach this issue with a different solution. @joelanford
There was a problem hiding this comment.
This "polling triggers an upgrade" test is one of the most important features of OLM, so we unfortunately can't "fake" it my touching the spec.
How is this accomplished in the current version of OLM? The use of make/sh/kinako(spelling), to get things into the cluster, the go to run tests, IMO blurs what is/isn't being tested, there aren't clear separation of duties in this model.
Correct me if I'm wrong, but I think you want an image loaded into the running cluster after the test has executed? Is that correct? Or do you just want this test to run longer to see if the polling picks up the the image already in the registry?
There was a problem hiding this comment.
How is this accomplished in the current version of OLM?
I'm not sure
The use of make/sh/kinako(spelling), to get things into the cluster, the go to run tests, IMO blurs what is/isn't being tested, there aren't clear separation of duties in this model.
I agree that the number of moving parts is a problem. I'm fairly confident that if we wanted something a bit leaner, we could build all of this in Go.
- Code in go that runs during an e2e that deploys an image registry in the cluster.
- Client-go code that runs
kubectl port-forwardto give the e2e test a way to communicate with the registry. - go-containerregistry code to push images, move tags, etc.
Correct me if I'm wrong, but I think you want an image loaded into the running cluster after the test has executed? Is that correct?
No, I don't think that is sufficient because the polling behavior of catalogd queries a remote registry. kind load would not make it visible to the polling process. What I'm after is $something that causes the digest of a tag to change mid way through the test. That could be one of:
- Pre-populating the registry with two catalog images as part of the setup, and then during the test re-tagging the second image over the first.
- Pushing the first image at
repo:tagas part of the setup, and then pushing the second image at that samerepo:tagduring the test.
Description
build-push-e2e-catalog.shto allow building and pushing new catalog imagetest-catalog:v2and resolves to a successful installfixes #945
Reviewer Checklist