Bug 1698377
| Summary: | Couldn't update elasticsearch CR successfully after deleting nodeSelector in clusterlogging CR. | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Qiaoling Tang <qitang> |
| Component: | Logging | Assignee: | ewolinet |
| Status: | CLOSED ERRATA | QA Contact: | Anping Li <anli> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.1.0 | CC: | anli, aos-bugs, ewolinet, jcantril, rmeggins |
| Target Milestone: | --- | ||
| Target Release: | 4.2.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | No Doc Update | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-10-16 06:28:05 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Qiaoling Tang
2019-04-10 09:24:12 UTC
This is strange that the elasticsearch CR would still have the nodeselector. can you provide the full output from `oc get elasticsearch elasticsearch -o yaml` ? The elasticsearch is updated. we can see the generation have changed from 7 to 11
apiVersion: logging.openshift.io/v1
kind: Elasticsearch
metadata:
creationTimestamp: 2019-04-11T14:33:35Z
generation: 11
name: elasticsearch
namespace: openshift-logging
ownerReferences:
- apiVersion: logging.openshift.io/v1
controller: true
kind: ClusterLogging
name: instance
uid: c9bdbd30-5c66-11e9-95a3-066c9806bef0
resourceVersion: "479698"
selfLink: /apis/logging.openshift.io/v1/namespaces/openshift-logging/elasticsearches/elasticsearch
uid: c9fc682f-5c66-11e9-8d1c-0e9e59f648a4
spec:
managementState: Managed
nodeSpec:
image: quay.io/openshift/origin-logging-elasticsearch5:latest
nodeSelector:
logging: es
resources:
limits:
memory: 2Gi
requests:
cpu: 200m
memory: 2Gi
nodes:
- genUUID: xc3ifgr1
nodeCount: 1
resources: {}
roles:
- client
- data
- master
storage:
size: 20G
storageClassName: gp2
redundancyPolicy: ZeroRedundancy
status:
clusterHealth: green
conditions: []
nodes:
- deploymentName: elasticsearch-cdm-xc3ifgr1-1
upgradeStatus: {}
pods:
client:
failed: []
notReady: []
ready:
- elasticsearch-cdm-xc3ifgr1-1-7d967d6855-qzjct
data:
failed: []
notReady: []
ready:
- elasticsearch-cdm-xc3ifgr1-1-7d967d6855-qzjct
master:
failed: []
notReady: []
ready:
- elasticsearch-cdm-xc3ifgr1-1-7d967d6855-qzjct
shardAllocationEnabled: all
The node selector is still on the elasticsearch CR...
This makes sense since we see in the CLO logs that it keeps evaluating that the CR nodeSelector isn't what it thinks it should be.
I'll try to recreate this as well.
spec:
managementState: Managed
nodeSpec:
image: quay.io/openshift/origin-logging-elasticsearch5:latest
nodeSelector:
logging: es
I noticed that if I scale down the EO before making a change to the ES CR we don't have an issue of the nodeSelector field persisting. Also, bumping the sdk (https://github.com/openshift/elasticsearch-operator/pull/122) resolves this issue. However, then we run into https://bugzilla.redhat.com/show_bug.cgi?id=1699015 which Joseph is currently working on a fix for. Moving to 4.2 as this can be worked around by: * Scaling down EO * Wait for CLO to update nodeSelector * Scale up EO Verified in ose-elasticsearch-operator-v4.2.0-201906241432 and ose-cluster-logging-operator-v4.2.0-201906241832 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, 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-2019:2922 |