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

K8SPG-454: set ready status when all pg pods are updated #869

Merged
merged 10 commits into from
Sep 5, 2024
Merged

Conversation

pooknull
Copy link
Contributor

@pooknull pooknull commented Aug 22, 2024

K8SPG-454 Powered by Pull Request Badge

https://perconadev.atlassian.net/browse/K8SPG-454

DESCRIPTION

Problem:
When pg instances are updated, the cluster status constantly switches between the initializing and ready states.

Cause:
The operator sets the ready status when all pg pods are ready. They are updated one by one. After each update, all pods are ready, so the operator switches to the ready state.

Solution:
Set the ready state when the sum of .status.instances[].updatedReplicas from crunchy's PostgresCluster is equal to the .status.postgres.size.

CHECKLIST

Jira

  • Is the Jira ticket created and referenced properly?
  • Does the Jira ticket have the proper statuses for documentation (Needs Doc) and QA (Needs QA)?
  • Does the Jira ticket link to the proper milestone (Fix Version field)?

Tests

  • Is an E2E test/test case added for the new feature/change?
  • Are unit tests added where appropriate?

Config/Logging/Testability

  • Are all needed new/changed options added to default YAML files?
  • Did we add proper logging messages for operator actions?
  • Did we ensure compatibility with the previous version or cluster upgrade process?
  • Does the change support oldest and newest supported PG version?
  • Does the change support oldest and newest supported Kubernetes version?

@pooknull pooknull marked this pull request as ready for review August 27, 2024 10:02
@egegunes
Copy link
Contributor

hmm in other operators we didn't have this field and didn't have the same problem. I wonder what's the difference?

@pooknull
Copy link
Contributor Author

pooknull commented Sep 4, 2024

hmm in other operators we didn't have this field and didn't have the same problem. I wonder what's the difference?

I have removed this new field: 4e1cd4a

@JNKPercona
Copy link
Collaborator

Test name Status
custom-extensions passed
demand-backup passed
finalizers passed
init-deploy passed
major-upgrade passed
monitoring passed
one-pod passed
operator-self-healing passed
pitr passed
scaling passed
scheduled-backup passed
self-healing passed
start-from-backup passed
tablespaces passed
telemetry-transfer passed
upgrade-consistency passed
upgrade-minor passed
users passed
We run 18 out of 18

commit: 3b669b5
image: perconalab/percona-postgresql-operator:PR-869-3b669b58d

@hors hors merged commit 50741ff into main Sep 5, 2024
17 checks passed
@hors hors deleted the dev/K8SPG-454 branch September 5, 2024 15:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants