Before this update, a version change of Elastic Cloud on Kubernetes (ECK) Operator from the previously tested version 1.6.0 to the latest release version 1.7.1 resulted in the Service Telemetry Operator no longer being able to request an ElasticSearch instance from the ECK Operator.
As a result, deployment of ElasticSearch was no longer possible with Service Telemetry Framework.
With this update, the updated ElasticSearch manifest template created by the Service Telemetry Operator uses elasticsearch.k8s.elastic.co/v1 instead of elasticsearch.k8s.elastic.co/v1beta1 and the parameters have been adjusted to be compatible with ECK v1.7.1.
Description of problem: The CustomResource created by Service Telemetry Operator for creating an ElasticSearch instance via ECK 1.7.1 no longer works due to the `podTemplate` and other values being marked as empty objects. This is not an issue with ECK 1.6.0.
Version-Release number of selected component (if applicable): STF 1.3, ECK 1.7.1
How reproducible: Always
Actual results:
Expected results:
And ElasticSearch CR should exist with a similar configuration to the following:
spec:
auth: {}
http:
service:
metadata:
creationTimestamp: null
spec: {}
tls:
certificate:
secretName: elasticsearch-es-cert
nodeSets:
- config:
node.data: true
node.ingest: true
node.master: true
node.store.allow_mmap: true
count: 1
name: default
podTemplate:
metadata:
labels:
tuned.openshift.io/elasticsearch: elasticsearch
spec:
containers:
- name: elasticsearch
resources:
limits:
cpu: "2"
memory: 4Gi
requests:
cpu: "1"
memory: 4Gi
volumes:
- emptyDir: {}
name: elasticsearch-data
transport:
service:
metadata:
creationTimestamp: null
spec: {}
tls:
certificate: {}
updateStrategy:
changeBudget: {}
version: 7.10.2
Instead, the `podTemplate` parameter is set to `podTemplate: {}`. Other parameters are also set like that, causing ElasticSearch to fail to be spun up.
Additional info: Doing a manual Subscription which sets the approval to manual and a startingCSV of elastic-cloud-eck.v1.6.0 causes everything to work properly, but setting any operator in a namespace to manual causes all operators in that namespace to be set to manual upgrades, meaning we lose our ability to have customers STF deployments automatically upgraded on release.
If an existing ECK with a working CR is upgraded from 1.6.0 to 1.7.1 then the elasticsearch CR is mangled, rendering the deployment invalid.
spec:
auth: {}
http:
service:
metadata: {}
spec: {}
tls:
certificate:
secretName: elasticsearch-es-cert
monitoring:
logs: {}
metrics: {}
nodeSets:
- config: {}
count: 1
name: default
podTemplate:
metadata:
creationTimestamp: null
spec:
containers: null
transport:
service:
metadata: {}
spec: {}
tls:
certificate: {}
updateStrategy:
changeBudget: {}
version: 7.10.2
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (Release of components for Service Telemetry Framework 1.3.2 - Container Images), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2021:3721
Description of problem: The CustomResource created by Service Telemetry Operator for creating an ElasticSearch instance via ECK 1.7.1 no longer works due to the `podTemplate` and other values being marked as empty objects. This is not an issue with ECK 1.6.0. Version-Release number of selected component (if applicable): STF 1.3, ECK 1.7.1 How reproducible: Always Actual results: Expected results: And ElasticSearch CR should exist with a similar configuration to the following: spec: auth: {} http: service: metadata: creationTimestamp: null spec: {} tls: certificate: secretName: elasticsearch-es-cert nodeSets: - config: node.data: true node.ingest: true node.master: true node.store.allow_mmap: true count: 1 name: default podTemplate: metadata: labels: tuned.openshift.io/elasticsearch: elasticsearch spec: containers: - name: elasticsearch resources: limits: cpu: "2" memory: 4Gi requests: cpu: "1" memory: 4Gi volumes: - emptyDir: {} name: elasticsearch-data transport: service: metadata: creationTimestamp: null spec: {} tls: certificate: {} updateStrategy: changeBudget: {} version: 7.10.2 Instead, the `podTemplate` parameter is set to `podTemplate: {}`. Other parameters are also set like that, causing ElasticSearch to fail to be spun up. Additional info: Doing a manual Subscription which sets the approval to manual and a startingCSV of elastic-cloud-eck.v1.6.0 causes everything to work properly, but setting any operator in a namespace to manual causes all operators in that namespace to be set to manual upgrades, meaning we lose our ability to have customers STF deployments automatically upgraded on release. If an existing ECK with a working CR is upgraded from 1.6.0 to 1.7.1 then the elasticsearch CR is mangled, rendering the deployment invalid. spec: auth: {} http: service: metadata: {} spec: {} tls: certificate: secretName: elasticsearch-es-cert monitoring: logs: {} metrics: {} nodeSets: - config: {} count: 1 name: default podTemplate: metadata: creationTimestamp: null spec: containers: null transport: service: metadata: {} spec: {} tls: certificate: {} updateStrategy: changeBudget: {} version: 7.10.2