CTA Schema Version Management

CTA has several versioned components which need to be aligned with the software version:

• Catalogue schema
• XRootD SSI protobuf version on client and server should match
• ObjectStore schema: this one is more tricky, as objects in the objectstore do not have to share the same schema version

Catalogue Schema version

• Current version is very close to the software version, which can be confusing.
• Catalogue schema version is major.minor.
• minor is incremented for additive changes: new tables and new columns. Adding to the DB can be done without any impact on the software version.
• major is incremented for non-backwards compatible changes: when tables/columns are removed or change type. Older software versions may not be compatible.

Catalogue Schema and software updates

Minor version changes

• Deploy new schema (does not affect current software version)
• When desired, add new software features that use the new schema and deploy at any subsequent time
• Less disruptive
• Disruption can still occur if different software components (frontend, tape servers) are communicating through the DB and are not in sync with the same schema version

Major version changes

• Schema update and software update must be done simultaneously
• More disruptive

Catalogue Schema version enforcement

• Currently we enforce that software will not start unless the major version is the same
• Minor version is allowed to be different
• It is currently possible for software to start with an older minor version, certain columns or tables may be missing.

Proposal

• Advance the catalogue schema version by some arbitrary amount, e.g. to version 10.0, to make it obvious that software version and catalogue version are decoupled.
• We should check both major and minor version on startup of frontend and tape servers:

if software_major_version == db_major_version
   and software_minor_version <= db_minor_version:
      /* OK to start */
   else:
      abort