This issue describes a possible improvement discussed in this PR thread, where we realized we are binding the creation / removal of Kubernetes primary and replica services with the client application lifecycles (i.e. with the logic inside mysql_provider.py module).
Ideally, we would bind these operations to the lifecycle of the MySQL application itself, reducing the number of scenarios when multiple client applications relate / unrelate.
Disclaimer
Kubernetes has a mechanism to bind an entity (i.e. a service) to the lifetime of another entity (i.e. statefulset or pod). It is critical that, if this mechanism is used, the binding happens to the statefulset, and not a pod. We cannot guaranteed that a pod called mysql-k8s/0 will always exists (i.e. scaling to 0 and back to N units, as unit identifiers do not get reused).
This issue describes a possible improvement discussed in this PR thread, where we realized we are binding the creation / removal of Kubernetes
primaryandreplicaservices with the client application lifecycles (i.e. with the logic inside mysql_provider.py module).Ideally, we would bind these operations to the lifecycle of the MySQL application itself, reducing the number of scenarios when multiple client applications relate / unrelate.
Disclaimer
Kubernetes has a mechanism to bind an entity (i.e. a service) to the lifetime of another entity (i.e. statefulset or pod). It is critical that, if this mechanism is used, the binding happens to the statefulset, and not a pod. We cannot guaranteed that a pod called
mysql-k8s/0will always exists (i.e. scaling to 0 and back to N units, as unit identifiers do not get reused).