Skip to content

K8SPG-698: create serviceaccount before statefulset #1125

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

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

pooknull
Copy link
Contributor

@pooknull pooknull commented Apr 9, 2025

K8SPG-698 Powered by Pull Request Badge

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

DESCRIPTION

Problem:
The cluster1-repo-host StatefulSet is created before its corresponding ServiceAccount cluster1-pgbackrest exists. This can cause failures in certain environments.

Solution:
Create ServiceAccount before the StatefulSet.

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?
  • Are all needed new/changed options added to the Helm Chart?
  • 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 April 9, 2025 21:32
@hors hors requested review from egegunes and gkech April 10, 2025 16:10
result.Requeue = true
return result, nil
}
// K8SPG-698: it should happen earlier
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we removed comments

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

}
serviceAccountName := sts.Spec.Template.Spec.ServiceAccountName
if serviceAccountName == "" {
panic("it's not expected to have empty service account name")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since checkObject(...) returns an error and when used we do this

	if err := sc.checkObject(ctx, obj); err != nil {
		panic(err) // should panic because reconciler can ignore the error
	}

I think this check can return an error and let the caller panic it. WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines 1656 to 1668
func (sc *saTestClient) Update(ctx context.Context, obj client.Object, opts ...client.UpdateOption) error {
if err := sc.checkObject(ctx, obj); err != nil {
panic(err) // should panic because reconciler can ignore the error
}
return sc.Client.Update(ctx, obj, opts...)
}

func (sc *saTestClient) Patch(ctx context.Context, obj client.Object, patch client.Patch, opts ...client.PatchOption) error {
if err := sc.checkObject(ctx, obj); err != nil {
panic(err) // should panic because reconciler can ignore the error
}
return sc.Client.Patch(ctx, obj, patch, opts...)
}
Copy link
Contributor

@gkech gkech Apr 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need these? Seems that they are not used in the test.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Crunchy code uses a patch request to create the ServiceAccount instead of a create request:

func (r *Reconciler) apply(ctx context.Context, object client.Object) error {
// Generate an apply-patch by comparing the object to its zero value.
zero := reflect.New(reflect.TypeOf(object).Elem()).Interface()
data, err := client.MergeFrom(zero.(client.Object)).Data(object)
apply := client.RawPatch(client.Apply.Type(), data)
// Keep a copy of the object before any API calls.
intent := object.DeepCopyObject()
patch := kubeapi.NewJSONPatch()
// Send the apply-patch with force=true.
if err == nil {
err = r.patch(ctx, object, apply, client.ForceOwnership)
}
// Some fields cannot be server-side applied correctly. When their outcome
// does not match the intent, send a json-patch to get really specific.
switch actual := object.(type) {
case *corev1.Service:
applyServiceSpec(patch, actual.Spec, intent.(*corev1.Service).Spec, "spec")
}
// Send the json-patch when necessary.
if err == nil && !patch.IsEmpty() {
err = r.patch(ctx, object, patch)
}
I will remove the update part

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pooknull pooknull requested a review from nmarukovich as a code owner April 14, 2025 13:10
@hors hors added this to the 2.7.0 milestone Apr 14, 2025
@gkech
Copy link
Contributor

gkech commented Apr 15, 2025

seems ok, let's check the golangci and the envtests why they are failing and then we can approve.

@JNKPercona
Copy link
Collaborator

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

commit: f24206a
image: perconalab/percona-postgresql-operator:PR-1125-f24206a27

@pooknull pooknull requested review from hors and gkech April 15, 2025 11:18
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.

4 participants