...

This document emphasize about the first part, but the second one could be implemented in the very same step.

Below are the motivations:

• Prevent accidental schema upgrades
• Provide administrator more detail and debugging information so they know how a schema upgrade is progressing
  • Add init method for xrootd to wait for schema upgrade to proceed
• Separation of xrootd and mariadb for development

Strategies

From inside the Pod running mysql

...

User friendliness for k8s admin: +++++ (the initContainer from the database pod initialize the database schema)

For xrootd add in schema upgrade flag file to signal to xrootd that schema upgrading is occurring.  xrootd startup script pauses if that flag is there.

Cons:

Need to start/stop mysqld inside the initContainer

mysql and entrypoint run be in the same initContainer

xrootd will fail until schema update and start/top mysqld finishes.

Example:

Current Qserv setup, works since ~2 years

...

WARNING: this strategy will require an additional network 'root@%' access to mysql, this is not a recommended for security.  The security consideration is that another pod could be scheduled to read data from localhost.  Note they would need to have the authentication credentials too to access data.

This strategy could apply for replication controller/replication database, but not for Czar and Worker which both embed their mysql container.

...