Objective

Extend the Replication system to support operations on the Qserv worker databases via worker's MariaDB service. The operations shall be broadcasted either to all known workers or a subset of those. Build the programmatic API, a command-line tool, REST API inside the Master Replication Controller, and the WEB UI.

This feature is needed for implementing the new catalog ingest in Qserv.

Operations to be supported

  • databases:
    • retrieving a list of known databases
    • creating
    • deleting
    • enable in Qserv (via Qserv worker?)
    • disable in Qserv (via Qserv worker?)
  • tables:
    • retrieving a list of known tables in a scope of a database
    • retrieving a schema
    • creating
    • deleting
    • modifying table schema (managing MySQL partitions)
  • privileges:
    • retrieving existing privileges for user qsmaster
    • granting privileges to user qsmaster to issues SELECT statements against all tables of a database
    • revoking privileges

Implementation details

Investigate pros and cons of the following options:

  • SQL: allowing a client to send arbitrary queries to be executed by MySQL user root.
  • functional: having a restricted mechanism which would support specific operations only.

Investigate two protocols:

  • XRootD/SSI: extend Qserv worker with the corresponding commands.
  • BOOST ASIO (with Protobuf serialization): extend Replication workers to handle the requests

The SQL option has a big advantage - it's flexibility. Once implemented and deployed it won't require to make any further modifications to the Qserv worker. 

And for the protocol options, the first one (XRootD/SSI) night seem to be easier, at least at the surface. However, it will also require the Qserv workers to be up in order to implement the operations. This would make replication database operations more fragile due to an additional dependency requirement (as compared to a dependency on the MAriaDB service of a worker node). In contrast with that a requirement for the BOOST ASIO option is to only have the worker's MariaDB server up, which will become a separate Docker container in the Kubernetes-based Qserv deployments. Another argument in favor of the second protocol option is that the Replication workers will need to be extended to talk to the worker's database servers anyway in order to implement the new catalog ingests. A known complication of the BOOST ASIO protocol is that it will require extending the Configuration (of the Replication system) to store connection parameters of the worker database services.

Enabling/disabling databases may still need to be implemented via XRootD/SSI to allow manipulating worker resources which:

  • would allow making changes on the fly w/o restarting Qserv
  • prevent removing resources which may be still in use

Investigate options to secure the protocol:

  • using the same secret file (string) which is already used by the existing wmgr Web service might be an option here
  • relying on the MariaDB password for the root account of the worker database services

The implementation should also protect published catalogs from being affected by the operations.

Preliminary choice:

  1. SQL over the functional
  2. BOOST ASIO (with Protobuf serialization) over XRootD/SSI
  3. using MariaDB authorization/authentication credentials to secure operations
    1. requiring credentials for interactive (command-line or Web UI) operations
    2. using credentials stored within the Replication System's Configuration for internal automation


  • No labels