-
Notifications
You must be signed in to change notification settings - Fork 84
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
statefulset: Use stateful sets for postgres deployments (PROJQUAY-6672) #980
Conversation
…y for authentication (PROJQUAY-2417) (quay#963) (quay#966) Missed that we need the certificate handling in the mirror pod when using Postgres SSL authentication Co-authored-by: Michaela Lang <[email protected]>
…ed clair resources (PROJQUAY-7993) (quay#970) The scale-down component was never rendered because of the incorrect path. The clair-postgres and clair-app needed to scale back after the postgres upgrade. This change ensures following flow in the case where clair is managed: - Scale down clair-app - Scale down clair-postgres - Upgrade clair-postgres - Scale up clair-postgres - Scale up clair-app --------- Co-authored-by: Shubhra Deshpande <shubhrajayant+github.com>
- Swap Postgres and Clair Postgres Deployments to StatefulSets
There should never be a case where we need to manage both deployments and statefulsets at the same time IMHO. Once the operator sees a deployment, it should shut down all Quay instances immediately and begin a migration from a deployment to a statefulset. There should be no instances of Quay or Clair running during the migration period, no jobs, no activity, apart from the migration pod. |
The check for both StatefulSet and Deployment is not intended to be about managing both simultaneously or during database migration. It's specifically to handle the transition period when upgrading the operator itself from a version that used Deployments to one that uses StatefulSets for Clair Postgres. This allows the operator to correctly identify the current state (Deployment or StatefulSet) and proceed with the appropriate upgrade path, ensuring a smooth transition between operator versions without assuming a specific resource type exists. The actual migration process from Deployment to StatefulSet would still occur as a separate, controlled step as you described. |
@deshpandevlab ah, gotcha, so it's only used for identification of the current state. Thanks! I misunderstood what the actual purpose is. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Conceptually it LGTM, I can't offer an in-depth code review as I'm not so familiar with the operator.
I assume this PR supersedes https://github.com/quay/quay-operator/pull/927/files?
/test ocp-latest-e2e test failed for mounting error. retrying the test |
@deshpandevlab: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
We're adding a check for Deployment here because during the migration process from Deployment to StatefulSet for the Clair Postgres component, we cannot assume that the StatefulSet will always be present. There may be instances where the old Deployment is still in use, especially if the upgrade process is ongoing or hasn't been initiated yet. This ensures that we can handle both the old Deployment-based setup and the new StatefulSet-based setup, providing a smoother transition and backwards compatibility during the upgrade process.
Testing