K8SPXC-1462: Restart PXC pods after monitor user password change

[s10]

---

Problem:
monitor user could be used not only in pmm sidecar containers, but in custom mysqld-exporter sidecar container running near pxc. If these custom sidecars are using monitor user, they need a pod restart after password change, same as pmm sidecars.

Cause:
monitor user password update causes pxc pods restart only when pmm is enabled

Solution:
Restart PXC pods without checking if a PMM is enabled.

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?
• Are OpenShift compare files changed for E2E tests (compare/*-oc.yml)?

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

[hors]

I do not like this idea. We should not have unneeded restarts. Maybe we can restart it if custom sidecar is used but up to @egegunes

[egegunes]

I agree with @hors, I don't think it's a good idea to restart PXC pods unless we know for sure that restart is needed.
@s10 how do you use monitor password in custom sidecar? env, envFromSecret or volume? maybe we can add a check for these and decide if restart is needed.

[s10]

I use envFromSecret:

    sidecars:
    - name: metrics
      image: prom/mysqld-exporter:v0.15.1
      env:
        - name: MYSQLD_EXPORTER_PASSWORD
          valueFrom:
            secretKeyRef:
              name: pxc-dev-1-secrets
              key: monitor
      ports:
        - name: metrics
          containerPort: 9104
      args:
        - "--mysqld.username=monitor"
        - "--mysqld.address=localhost:3306"
        - "--collect.binlog_size"
 ...

[egegunes]

It might be good to check keys for system usernames in env and envFromSecret of sidecar container and decide if it needs a restart. wdyt @hors @spron-in?

[hors]

It might be good to check keys for system usernames in env and envFromSecret of sidecar container and decide if it needs a restart. wdyt @hors @spron-in?

It is a good idea.

[spron-in]

I understand the desire to minimize the number of restarts, but also want to be sure that we are not overcomplicating it here.
I would not expect a user to change the password for monitor user too often or to change it when monitoring in some form is not enabled.
So we are going to implement more checks for quite a rare operation and the operation that actually justifies pod restart.

Am I looking at it wrong?

[egegunes]

@spron-in i really don't want to restart PXC pods blindly. we can always say user should restart pods themselves but if we want to do it in automatic way, i believe current changes look good.

[egegunes]

@inelpandzic please review

[JNKPercona]

Test name	Status
affinity-8-0	passed
auto-tuning-8-0	passed
cross-site-8-0	passed
custom-users-8-0	passed
demand-backup-cloud-8-0	passed
demand-backup-encrypted-with-tls-8-0	passed
demand-backup-8-0	passed
haproxy-5-7	passed
haproxy-8-0	passed
init-deploy-5-7	passed
init-deploy-8-0	passed
limits-8-0	passed
monitoring-2-0-8-0	passed
one-pod-5-7	passed
one-pod-8-0	passed
pitr-8-0	passed
pitr-gap-errors-8-0	passed
proxy-protocol-8-0	passed
proxysql-sidecar-res-limits-8-0	passed
pvc-resize-5-7	passed
pvc-resize-8-0	passed
recreate-8-0	passed
restore-to-encrypted-cluster-8-0	failure
scaling-proxysql-8-0	passed
scaling-8-0	passed
scheduled-backup-5-7	passed
scheduled-backup-8-0	passed
security-context-8-0	passed
smart-update1-8-0	passed
smart-update2-8-0	passed
storage-8-0	passed
tls-issue-cert-manager-ref-8-0	passed
tls-issue-cert-manager-8-0	passed
tls-issue-self-8-0	passed
upgrade-consistency-8-0	passed
upgrade-haproxy-5-7	passed
upgrade-haproxy-8-0	passed
upgrade-proxysql-5-7	passed
upgrade-proxysql-8-0	failure
users-5-7	passed
users-8-0	passed
validation-hook-8-0	passed
We run 42 out of 42

commit: fc65a9b
image: perconalab/percona-xtradb-cluster-operator:PR-1816-fc65a9be