Skip to content
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

Non-existing statefulsets are being deleted over and over #1751

Open
wonko opened this issue Dec 9, 2024 · 0 comments
Open

Non-existing statefulsets are being deleted over and over #1751

wonko opened this issue Dec 9, 2024 · 0 comments
Labels

Comments

@wonko
Copy link

wonko commented Dec 9, 2024

Report

I noticed that the percona mongodb operator fills my kube API logs with deletes of non-existant stateful sets every couple of seconds. This clutters the logs and spills resources on the API server.

In my case, where I run 2 mongos and an arbiter, I get a delete for sts's:

  • clustername-cfg
  • clustername-mongos
  • clustername-rs0-nv

every 6 seconds. See the below screenshot.
Screenshot 2024-12-09 at 20 00 26

More about the problem

Checking the codepaths, I see that it might be intended behaviour (the delete is done, and a k8serror.IsNotFound(err) is actually in place to ignore this error, see https://github.com/percona/percona-server-mongodb-operator/blob/main/pkg/controller/perconaservermongodb/psmdb_controller.go#L995 for one example).

This seems wrong, I'd assume that after a single attempt, the logic can be stopped to try and delete a non-existing object.

Steps to reproduce

  1. deploy the example crd, just adjust to have 1 arbiter and 2 mongos.
  2. make sure to disable the sharding
  3. observe the kube API logs once everything is deployed

Versions

  1. Kubernetes - GKE 1.31
  2. Operator - latest
  3. Database - latest

Anything else?

No response

@wonko wonko added the bug label Dec 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant