K8PS-212 cr validations for async cluster type

[gkech]

CHANGE DESCRIPTION

Problem:
Related PR: #308

Below we have some example of the validations. At the last example we apply the cr with the default values as they are committed in main.

Image: perconalab/percona-server-mysql-operator:K8SPS-212-4

Cause:
Short explanation of the root cause of the issue if applicable.

Solution:
Short explanation of the solution we are providing with this PR.

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 PS version?
• Does the change support oldest and newest supported Kubernetes version?

[nmarukovich]

Maybe it also makes sense to change in our CR orchestrator.enabled true -> false as we use group replication.

And also I have a question maybe for @egegunes @hors I don't remember why we use GR in cr.yaml, but if the value is empty we use Async
Should we use GR in this case too?

if len(cr.Spec.MySQL.ClusterType) == 0 {
		cr.Spec.MySQL.ClusterType = ClusterTypeAsync
	}

[gkech]

Maybe it also makes sense to change in our CR orchestrator.enabled true -> false as we use group replication.

And also I have a question maybe for @egegunes @hors I don't remember why we use GR in cr.yaml, but if the value is empty we use Async Should we use GR in this case too?

if len(cr.Spec.MySQL.ClusterType) == 0 {
		cr.Spec.MySQL.ClusterType = ClusterTypeAsync
	}

addressed ✅

[gkech]

We could introduce more validations e.g. for the cluster sizes, but adding them now means that we will start effecting the unit testing we have like

var _ = Describe("Unsafe configurations", Ordered, func() {
	....

This could also mean that the old validations will become obsolete. We will keep the focus for now only on the cluster type as we initially discussed, and followup with adding more rules here as part of a new ticket that also removes some of the old validations.

[JNKPercona]

Test name	Status
version-service	passed
async-ignore-annotations	passed
auto-config	passed
config	passed
config-router	passed
demand-backup	passed
gr-demand-backup	passed
gr-demand-backup-haproxy	passed
gr-finalizer	passed
gr-haproxy	passed
gr-ignore-annotations	passed
gr-init-deploy	passed
gr-one-pod	passed
gr-recreate	passed
gr-scaling	passed
gr-scheduled-backup	passed
gr-security-context	passed
gr-self-healing	passed
gr-tls-cert-manager	passed
gr-users	passed
haproxy	passed
init-deploy	passed
limits	passed
monitoring	passed
one-pod	passed
operator-self-healing	passed
recreate	passed
scaling	passed
scheduled-backup	passed
service-per-pod	passed
sidecars	passed
smart-update	passed
tls-cert-manager	passed
users	passed
We run 34 out of 34

commit: b4b31d8
image: perconalab/percona-server-mysql-operator:PR-856-b4b31d89