search

SumoLogic / sumologic-kubernetes-collection

Sumo Logic collection solution for Kubernetes
Apache License 2.0
147 stars 183 forks source link

setup shouldn't be rerun after innocent changes #2228

Open tavin opened 2 years ago

tavin commented 2 years ago

Note that we use helmfile; it runs helm upgrade. After an initial rollout I wasn't happy with the default for fluentd.logs.containers.sourceCategoryReplaceDash so I changed it (to a dash, apparently there's no way to simply turn it off). The process of applying the change seemed to hang forever so I aborted it and started debugging.

The problem was that it insists on rerunning the initial setup job. I guess the workaround is easy to figure out once you've arrived at this point. But it shouldn't do that.

1 release(s) matching name=kubernetes-collection found in helmfile.yml

Affected releases are:
  kubernetes-collection (sumologic/sumologic) UPDATED

processing 1 groups of releases in this order:
GROUP RELEASES
1     arn:aws:eks:.../sumologic/kubernetes-collection

processing releases in group 1/1: arn:aws:eks:.../sumologic/kubernetes-collection
Upgrading release=kubernetes-collection, chart=sumologic/sumologic
exec: helm --kube-context arn:aws:eks:... upgrade --install --reset-values kubernetes-collection sumologic/sumologic --create-namespace --kube-context arn:aws:eks:... --namespace sumologic --values /tmp/helmfile... --history-max 10 --debug
helm:yRLZs> history.go:56: [debug] getting history for release kubernetes-collection
helm:yRLZs> upgrade.go:142: [debug] preparing upgrade for kubernetes-collection
helm:yRLZs> upgrade.go:499: [debug] resetting values to the chart's original version
helm:yRLZs> upgrade.go:150: [debug] performing update for kubernetes-collection
helm:yRLZs> upgrade.go:322: [debug] creating upgraded release for kubernetes-collection
helm:yRLZs> client.go:299: [debug] Starting delete for "kubernetes-collection-sumologic-setup" ServiceAccount
helm:yRLZs> client.go:128: [debug] creating 1 resource(s)
helm:yRLZs> client.go:299: [debug] Starting delete for "kubernetes-collection-sumologic-setup" ClusterRole
helm:yRLZs> client.go:128: [debug] creating 1 resource(s)
helm:yRLZs> client.go:299: [debug] Starting delete for "kubernetes-collection-sumologic-setup" ConfigMap
helm:yRLZs> client.go:128: [debug] creating 1 resource(s)
helm:yRLZs> client.go:299: [debug] Starting delete for "kubernetes-collection-sumologic-setup" ClusterRoleBinding
helm:yRLZs> client.go:128: [debug] creating 1 resource(s)
helm:yRLZs> client.go:299: [debug] Starting delete for "kubernetes-collection-sumologic-setup-custom" ConfigMap
helm:yRLZs> client.go:128: [debug] creating 1 resource(s)
helm:yRLZs> client.go:299: [debug] Starting delete for "kubernetes-collection-sumologic-setup" Job
helm:yRLZs> client.go:128: [debug] creating 1 resource(s)
helm:yRLZs> client.go:529: [debug] Watching for changes to Job kubernetes-collection-sumologic-setup with timeout of 5m0s
helm:yRLZs> client.go:557: [debug] Add/Modify event for kubernetes-collection-sumologic-setup: ADDED
client.go:596: [debug] kubernetes-collection-sumologic-setup: Jobs active: 1, jobs failed: 0, jobs succeeded: 0
^Chelm:yRLZs> Release kubernetes-collection has been cancelled.
helm:yRLZs> upgrade.go:431: [debug] warning: Upgrade "kubernetes-collection" failed: context canceled
err: Received [interrupt] to shutdown

Some text above has been redacted with ellipses.

sumo-drosiek commented 2 years ago

Hi,

We are aware of this behavior. We are planning to change this behavior when we have an operator for our collection, unfortunately we are not able to provide ETA yet.

For now, setup can be disabled by setting sumologic.setupEnabled property to false