-
Notifications
You must be signed in to change notification settings - Fork 233
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Operator is constantly trying to update OpensearchUser #633
Comments
Hi @evheniyt . |
@IIIRADIII very basic configuration for cluster and user apiVersion: opensearch.opster.io/v1
kind: OpenSearchCluster
metadata:
annotations:
meta.helm.sh/release-name: test
meta.helm.sh/release-namespace: opensearch-test
labels:
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/version: 2.7.0
helm.sh/chart: test-opensearch-1.0.0
name: test-opensearch
namespace: opensearch-test
spec:
bootstrap:
affinity: {}
resources: {}
confMgmt: {}
dashboards:
affinity: {}
enable: true
image: docker.io/opensearchproject/opensearch-dashboards:2.7.0
imagePullPolicy: IfNotPresent
opensearchCredentialsSecret: {}
podSecurityContext: {}
replicas: 1
resources: {}
securityContext: {}
service:
type: ClusterIP
tls:
caSecret: {}
generate: true
secret: {}
version: 2.7.0
general:
drainDataNodes: true
httpPort: 9200
image: docker.io/opensearchproject/opensearch:2.7.0
imagePullPolicy: IfNotPresent
monitoring:
scrapeInterval: 30s
tlsConfig: {}
podSecurityContext: {}
securityContext: {}
serviceName: test-opensearch
setVMMaxMapCount: true
vendor: Opensearch
version: 2.7.0
initHelper:
imagePullPolicy: IfNotPresent
resources: {}
version: 1.27.2-buildx
nodePools:
- component: masters
diskSize: 30Gi
replicas: 3
resources:
limits:
cpu: 500m
memory: 2Gi
requests:
cpu: 500m
memory: 2Gi
roles:
- master
- data
security:
config:
adminCredentialsSecret: {}
adminSecret: {}
securityConfigSecret: {}
tls:
http:
caSecret: {}
generate: true
secret: {}
transport:
caSecret: {}
generate: true
perNode: true
secret: {} apiVersion: opensearch.opster.io/v1
kind: OpensearchUser
metadata:
name: test-user
namespace: opensearch-test
spec:
opensearchCluster:
name: test-opensearch
passwordFrom:
key: test
name: users-credentials |
Same here with apiVersion: opensearch.opster.io/v1
kind: OpensearchRole
metadata:
name: dashboards-role
spec:
opensearchCluster:
name: opensearch-cluster
clusterPermissions:
- cluster_monitor
- cluster_composite_ops
- manage_point_in_time
- indices:admin/template*
- indices:admin/index_template*
- indices:data/read/scroll*
indexPermissions:
- indexPatterns:
- ".kibana"
- ".opensearch_dashboards"
allowedActions:
- indices_all
- indexPatterns:
- ".kibana-6"
- ".opensearch_dashboards-6"
allowedActions:
- indices_all
- indexPatterns:
- ".kibana_*"
- ".opensearch_dashboards_*"
allowedActions:
- indices_all
- indexPatterns:
- ".tasks"
allowedActions:
- indices_all
- indexPatterns:
- ".management-beats*"
allowedActions:
- indices_all
- indexPatterns:
- "*"
allowedActions:
- indices:admin/aliases*
|
Looks like the problem is in different types of
Here is the output for
Because nil slice is not the same as [] slice |
…ler (#727) ### Description Fixes #633 Fixes #731 Based on investigations [here](#633 (comment)) and [here](#731 (comment)) it was found that a discrepancy between `<nil slice>` and `<[] slice>` is causing the operator to constantly update User, Role, IndexTemplate, etc. Also, the current log level for User reconciles produces too many logs, so increasing its level may be a good idea here. Because of the issue with comparing `nil` and empty slices, I have replaced `reflect.DeepEqual` with `comp.Equal`. Also, added a helper function that will sort nested json keys in cases when API returns unsorted keys which is casing comparing to return diff. ### Issues Resolved Closes #633 Closes #731 By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. For more information on following Developer Certificate of Origin and signing off your commits, please check [here](https://github.com/opensearch-project/OpenSearch/blob/main/CONTRIBUTING.md#developer-certificate-of-origin). --------- Signed-off-by: Yevhenii Tiutiunnyk <[email protected]>
…ler (opensearch-project#727) ### Description Fixes opensearch-project#633 Fixes opensearch-project#731 Based on investigations [here](opensearch-project#633 (comment)) and [here](opensearch-project#731 (comment)) it was found that a discrepancy between `<nil slice>` and `<[] slice>` is causing the operator to constantly update User, Role, IndexTemplate, etc. Also, the current log level for User reconciles produces too many logs, so increasing its level may be a good idea here. Because of the issue with comparing `nil` and empty slices, I have replaced `reflect.DeepEqual` with `comp.Equal`. Also, added a helper function that will sort nested json keys in cases when API returns unsorted keys which is casing comparing to return diff. ### Issues Resolved Closes opensearch-project#633 Closes opensearch-project#731 By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license. For more information on following Developer Certificate of Origin and signing off your commits, please check [here](https://github.com/opensearch-project/OpenSearch/blob/main/CONTRIBUTING.md#developer-certificate-of-origin). --------- Signed-off-by: Yevhenii Tiutiunnyk <[email protected]> Signed-off-by: Sebastian Woehrl <[email protected]>
After we had created users with
OpensearchUser
we noticed that operator is constantly trying to update all created users even when there were no changes.In operator logs we could see:
In
OpensearchUser
events we could see thatOpensearchAPIUpdated
counter is constantly increasing:Unfortunately, from the code it's not clear why exactly that happens, looks like this
reflect.DeepEqual(user, userResponse[username])
could be the root cause. I think to understand what is not equal between the current user and the response that operator gets there should be some additional logs (e.g. what exactly is different)Opensearch version 2.3.0
Operator version 2.4.0
The text was updated successfully, but these errors were encountered: