The main migration tool container and the sidecar cloud_sql_proxy container have independent lifecycles, even though
they are functionally dependent on each other.
Theoretically, the migration tool container could be quicker than the sidecar and could start running its commands before
the cloud_sql_proxy ever gets to open up connections to the DB.
This is currently mitigated by a hard constant-time sleep in the migration tool container.
We could theoretically explicitly wait for the could_sql_proxy instead of sleeping.
The main migration tool container and the sidecar cloud_sql_proxy container have independent lifecycles, even though they are functionally dependent on each other.
Theoretically, the migration tool container could be quicker than the sidecar and could start running its commands before the cloud_sql_proxy ever gets to open up connections to the DB.
This is currently mitigated by a hard constant-time
sleep
in the migration tool container. We could theoretically explicitly wait for the could_sql_proxy instead of sleeping.