Open james-callahan opened 2 months ago
hi @james-callahan the workaround is to set custom initImage via CR
Yes I have had to use that as a workaround for now. However it introduces unwanted coupling between deploying the CR and the version of the operator in use.
hi @james-callahan the workaround is to set custom initImage via CR
Yes I have had to use that as a workaround for now. However it introduces unwanted coupling between deploying the CR and the version of the operator in use.
I see your point. I think we can improve it but you will need to have *:1.15.0*
in your tag. Without it operator can't understand the operator version. I will create jira task for this improvement.
@james-callahan I have created jira task https://perconadev.atlassian.net/browse/K8SPXC-1469
Report
initImage
doesn't match that of operator resulting in failureMore about the problem
I hash-lock (i.e. use a digest) to run the operator, i.e. the operator deployment has
image: percona/percona-xtradb-cluster-operator:1.15.0@sha256:6f7d8d4e472b8c4d166573cc7bb714bbb0fdf1535142b6138c62fdecbf881df9
When the operator attempts to figure out the init image to use (at https://github.com/percona/percona-xtradb-cluster-operator/blob/fc46e369c9cc1bfca4552fdc6b204f9b5b243227/pkg/k8s/utils.go#L45-L56) it looks at it's own image and tries to figure out what init image to use. With the above image, that results in a different image (probably takes the
imageName = strings.Split(imageName, ":")[0] + ":" + cr.Spec.CRVersion
path)However, my cluster has security rules that prevent unhashlocked images. So the pod fails to get created.
Steps to reproduce
image: percona/percona-xtradb-cluster-operator:1.15.0@sha256:6f7d8d4e472b8c4d166573cc7bb714bbb0fdf1535142b6138c62fdecbf881df9
)Versions
Anything else?
No response