[Chore] Use OTEL operator with pinned version in upstream CI and fix tests #1086
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1086 +/- ##
=======================================
Coverage 58.64% 58.64%
=======================================
Files 113 113
Lines 10145 10145
=======================================
Hits 5950 5950
Misses 3892 3892
Partials 303 303
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
IshwarKanse
force-pushed
the
fixes
branch
2 times, most recently
from
3233e04 to
928bfa5
Compare
|
The OTEL operator bundle intermittently fails to install in Kind cluster. |
IshwarKanse
force-pushed
the
fixes
branch
4 times, most recently
from
7b1d8fb to
0b65d67
Compare
|
@pavolloffay @andreasgerstmayr Can you help to review and approve this PR. |
Let's merge #1092 first (large PR) to not cause merge conflicts for #1092 |
| .PHONY: otel-deploy | ||
| otel-deploy: operator-sdk ## Deploy OpenTelemetry operator via OLM | ||
| kubectl create namespace otel-operator-system | ||
| # Wait for OLM components to be ready |
There was a problem hiding this comment.
Why does the otel-deploy target need to wait for the OLM installation, shouldn't the place where OLM is installed wait for completion?
| apiVersion: v1 | ||
| kind: ConfigMap | ||
| apiVersion: opentelemetry.io/v1beta1 | ||
| kind: OpenTelemetryCollector |
There was a problem hiding this comment.
The advantage of using a Deployment instead of the OpenTelemetry CR is that we don't have a dependency on the OpenTelemetry Operator when running the tests from the e2e test suite. We already have a dependency on the OTEL Operator for the OpenShift e2e test suite.
wdyt @pavolloffay @rubenvp8510, should we mandate an OTEL Operator installation for the Tempo e2e tests? Or keep the dependencies small?
I tend to prefer to keep the dependencies minimal, i.e. just use a Deployment for the Tempo e2e tests.
There was a problem hiding this comment.
I also tend to prefer to keep the dependencies at minimum. What exactly is the advantage of using the OTEL operator instead? It is to not have to bump otel version manually in each deployment?
There was a problem hiding this comment.
With a deployment we need to update its spec and related resources if we want to bump the collector version. Its not as simple as changing the image tag ref, for some reason GRPC was not working with deployment when I used the latest collector version and I had to try to figure out what was missing. With operator its much easier, we just update the operator version var in the Makefile (Until the API version changes in CRD :) ) When the tests run on an OpenShift cluster the tests/e2e suite with a deployment runs with the older version of collector. If we use the operator, the tests will run using the operator version installed on the OCP cluster. It could be any version we want to test with Tempo.
The PR adds the following changes: