ghga/metldata repository overview

⁠Metldata

metldata - A framework for handling metadata based on ETL, CQRS, and event sourcing.

⁠Description

Metldata is a framework for handling the entire lifetime of metadata by addressing the a complex combination of challenges that makes it suitable especially for public archives for sensitive data:

Figure 1| Overview of the combination of challenges during metadata handling.

⁠Immutability

It is guaranteed that data entries do not change over time making reproducibility possible without having to rely on local snapshots.

⁠Accessibility

A stable accession is assigned to each resource. Together with the immutability property, this guarantees that you will always get the same data when querying with the same accession.

⁠Corrections, Improvements, Extensions

Even though data is stored in an immutable way, the metldata still allows for corrections, improvements, and extensions of submitted data. This is achieved my not just storing the current state of a submission but by persisting a version history. Thereby, modifications are realized by issuing a new version of the submission without affecting the content of existing versions.

⁠Transparency

The version history not only resolved the conflict between immutability and the need to evolve and adapt data, it also make the changes transparent to user relying on the data.

⁠Multiple Representations

Often, the requirements regarding the structure and content of data differs depending the use case and the audience. Metldata accounts for this by proving a configurable workflow engine for transforming submitted metadata into multiple representation of that data.

⁠GDPR Compliance

The GDPR gives data subjects the right to issue a request to delete data. Metldata complies with this demand. Thereby, only entire versions of a submission can be deleted. The associated accessions stay available so that user are informed that the associated data is not available anymore. The guarantees for immutability and stability of accessions are not violated, however, data might become unavailable.

⁠Installation

We recommend using the provided Docker container.

A pre-built version is available on Docker Hub⁠:

docker pull ghga/metldata:4.2.1

Or you can build the container yourself from the ./Dockerfile⁠:

# Execute in the repo's root dir:
docker build -t ghga/metldata:4.2.1 .

For production-ready deployment, we recommend using Kubernetes. However for simple use cases, you could execute the service using docker on a single server:

# The entrypoint is pre-configured:
docker run -p 8080:8080 ghga/metldata:4.2.1 --help

If you prefer not to use containers, you may install the service from source:

# Execute in the repo's root dir:
pip install .

# To run the service:
metldata --help

⁠Configuration

⁠Parameters

The service requires the following configuration parameters:

• log_level (string): The minimum log level to capture. Must be one of: "CRITICAL", "ERROR", "WARNING", "INFO", "DEBUG", or "TRACE". Default: "INFO".

• service_name (string): Default: "metldata".

• service_instance_id (string, required): A string that uniquely identifies this instance across all instances of this service. A globally unique Kafka client ID will be created by concatenating the service_name and the service_instance_id.

  Examples:

  "germany-bw-instance-001"
  

  Copy

• log_format: If set, will replace JSON formatting with the specified string format. If not set, has no effect. In addition to the standard attributes, the following can also be specified: timestamp, service, instance, level, correlation_id, and details. Default: null.

  • Any of
    • string
    • null

  Examples:

  "%(timestamp)s - %(service)s - %(level)s - %(message)s"
  

  Copy

  "%(asctime)s - Severity: %(levelno)s - %(msg)s"
  

  Copy

• log_traceback (boolean): Whether to include exception tracebacks in log messages. Default: true.

• mongo_dsn (string, format: multi-host-uri, required): MongoDB connection string. Might include credentials. For more information see: https://naiveskill.com/mongodb-connection-string/⁠. Length must be at least 1.

  Examples:

  "mongodb://localhost:27017"
  

  Copy

• db_name (string, required): Name of the database located on the MongoDB server.

  Examples:

  "my-database"
  

  Copy

• mongo_timeout: Timeout in seconds for API calls to MongoDB. The timeout applies to all steps needed to complete the operation, including server selection, connection checkout, serialization, and server-side execution. When the timeout expires, PyMongo raises a timeout exception. If set to None, the operation will not time out (default MongoDB behavior). Default: null.

  • Any of
    • integer: Exclusive minimum: 0.
    • null

  Examples:

  300
  

  Copy

  600
  

  Copy

  null
  

  Copy

• kafka_servers (array, required): A list of connection strings to connect to Kafka bootstrap servers.

  • Items (string)

  Examples:

  [
      "localhost:9092"
  ]
  

  Copy

• kafka_security_protocol (string): Protocol used to communicate with brokers. Valid values are: PLAINTEXT, SSL. Must be one of: "PLAINTEXT" or "SSL". Default: "PLAINTEXT".

• kafka_ssl_cafile (string): Certificate Authority file path containing certificates used to sign broker certificates. If a CA is not specified, the default system CA will be used if found by OpenSSL. Default: "".

• kafka_ssl_certfile (string): Optional filename of client certificate, as well as any CA certificates needed to establish the certificate's authenticity. Default: "".

• kafka_ssl_keyfile (string): Optional filename containing the client private key. Default: "".

• kafka_ssl_password (string, format: password, write-only): Optional password to be used for the client private key. Default: "".

• generate_correlation_id (boolean): A flag, which, if False, will result in an error when inbound requests don't possess a correlation ID. If True, requests without a correlation ID will be assigned a newly generated ID in the correlation ID middleware function. Default: true.

  Examples:

  true
  

  Copy

  false
  

  Copy

• kafka_max_message_size (integer): The largest message size that can be transmitted, in bytes, before compression. Only services that have a need to send/receive larger messages should set this. When used alongside compression, this value can be set to something greater than the broker's message.max.bytes field, which effectively concerns the compressed message size. Exclusive minimum: 0. Default: 1048576.

  Examples:

  1048576
  

  Copy

  16777216
  

  Copy

• kafka_compression_type: The compression type used for messages. Valid values are: None, gzip, snappy, lz4, and zstd. If None, no compression is applied. This setting is only relevant for the producer and has no effect on the consumer. If set to a value, the producer will compress messages before sending them to the Kafka broker. If unsure, zstd provides a good balance between speed and compression ratio. Default: null.

  • Any of
    • string: Must be one of: "gzip", "snappy", "lz4", or "zstd".
    • null

  Examples:

  null
  

  Copy

  "gzip"
  

  Copy

  "snappy"
  

  Copy

  "lz4"
  

  Copy

  "zstd"
  

  Copy

• kafka_max_retries (integer): The maximum number of times to immediately retry consuming an event upon failure. Works independently of the dead letter queue. Minimum: 0. Default: 0.

  Examples:

  0
  

  Copy

  1
  

  Copy

  2
  

  Copy

  3
  

  Copy

  5
  

  Copy

• kafka_enable_dlq (boolean): A flag to toggle the dead letter queue. If set to False, the service will crash upon exhausting retries instead of publishing events to the DLQ. If set to True, the service will publish events to the DLQ topic after exhausting all retries. Default: false.

  Examples:

  true
  

  Copy

  false
  

  Copy

• kafka_dlq_topic (string): The name of the topic used to resolve error-causing events. Default: "dlq".

  Examples:

  "dlq"
  

  Copy

• kafka_retry_backoff (integer): The number of seconds to wait before retrying a failed event. The backoff time is doubled for each retry attempt. Minimum: 0. Default: 0.

  Examples:

  0
  

  Copy

  1
  

  Copy

  2
  

  Copy

  3
  

  Copy

  5
  

  Copy

• artifact_topic (string, required): Name of the event topic containing artifact events.

  Examples:

  "artifacts"
  

  Copy

• resource_change_topic (string, required): Name of the topic used for events informing other services about resource changes, i.e. deletion or insertion.

  Examples:

  "searchable_resources"
  

  Copy

• resource_deletion_type (string, required): Type used for events indicating the deletion of a previously existing resource.

  Examples:

  "searchable_resource_deleted"
  

  Copy

• resource_upsertion_type (string, required): Type used for events indicating the upsert of a resource.

  Examples:

  "searchable_resource_upserted"
  

  Copy

• dataset_change_topic (string, required): Name of the topic announcing, among other things, the list of files included in a new dataset.

  Examples:

  "metadata_datasets"
  

  Copy

• dataset_deletion_type (string, required): Event type used for communicating dataset deletions.

  Examples:

  "dataset_deleted"
  

  Copy

• dataset_upsertion_type (string, required): Event type used for communicating dataset upsertions.

  Examples:

  "dataset_upserted"
  

  Copy

• primary_artifact_name (string, required): Name of the artifact from which the information for outgoing change events is derived.

  Examples:

  "embedded_public"
  

  Copy

• primary_dataset_name (string, required): Name of the resource class corresponding to the embedded_dataset slot.

  Examples:

  "EmbeddedDataset"
  

  Copy

• host (string): IP of the host. Default: "127.0.0.1".

• port (integer): Port to expose the server on the specified host. Default: 8080.

• auto_reload (boolean): A development feature. Set to True to automatically reload the server upon code changes. Default: false.

• workers (integer): Number of workers processes to run. Default: 1.

• timeout_keep_alive (integer): The time in seconds to keep an idle connection open for subsequent requests before closing it. This value should be higher than the timeout used by any client or reverse proxy to avoid premature connection closures. Default: 90.

  Examples:

  5
  

  Copy

  90
  

  Copy

  5400
  

  Copy

• api_root_path (string): Root path at which the API is reachable. This is relative to the specified host and port. Default: "".

• openapi_url (string): Path to get the openapi specification in JSON format. This is relative to the specified host and port. Default: "/openapi.json".

• docs_url (string): Path to host the swagger documentation. This is relative to the specified host and port. Default: "/docs".

• cors_allowed_origins: A list of origins that should be permitted to make cross-origin requests. By default, cross-origin requests are not allowed. You can use ['*'] to allow any origin. Default: null.

  • Any of
    • array
      • Items (string)
    • null

  Examples:

  [
      "https://example.org",
      "https://www.example.org"
  ]
  

  Copy

• cors_allow_credentials: Indicate that cookies should be supported for cross-origin requests. Defaults to False. Also, cors_allowed_origins cannot be set to ['*'] for credentials to be allowed. The origins must be explicitly specified. Default: null.

  • Any of
    • boolean
    • null

  Examples:

  [
      "https://example.org",
      "https://www.example.org"
  ]
  

  Copy

• cors_allowed_methods: A list of HTTP methods that should be allowed for cross-origin requests. Defaults to ['GET']. You can use ['*'] to allow all standard methods. Default: null.

  • Any of
    • array
      • Items (string)
    • null

  Examples:

  [
      "*"
  ]
  

  Copy

• cors_allowed_headers: A list of HTTP request headers that should be supported for cross-origin requests. Defaults to []. You can use ['*'] to allow all request headers. The Accept, Accept-Language, Content-Language, Content-Type and some are always allowed for CORS requests. Default: null.

  • Any of
    • array
      • Items (string)
    • null

  Examples:

  []
  

  Copy

• cors_exposed_headers: A list of HTTP response headers that should be exposed for cross-origin responses. Defaults to []. Note that you can NOT use ['*'] to expose all response headers. The Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified and Pragma headers are always exposed for CORS responses. Default: null.

  • Any of
    • array
      • Items (string)
    • null

  Examples:

  []
  

  Copy

• artifact_infos (array, required): Information for artifacts to be queryable via the Artifacts REST API.

  • Items: Refer to #/$defs/ArtifactInfo⁠.

• loader_token_hashes (array, required): Hashes of tokens used to authenticate for loading artifact.

  • Items (string)

• publishable_artifacts (array): List of artifacts to be published in their entirety when loaded into the Loader API.

  • Items (string)

  Examples:

  []
  

  Copy

  [
      "added_accessions"
  ]
  

  Copy

⁠Definitions

• AnchorPoint (object): A model for describing an anchor point for the specified target class.
  • target_class (string, required): The name of the class to be targeted.
  • identifier_slot (string, required): The name of the slot in the target class that is used as identifier.
  • root_slot (string, required): The name of the slot in the root class used to link to the target class.
• ArtifactInfo (object): Model to describe general information on an artifact. Please note, it does not contain actual artifact instances derived from specific metadata.
  • name (string, required): The name of the artifact.
  • description (string, required): A description of the artifact.
  • resource_classes (object, required): A dictionary of resource classes for this artifact. The keys are the names of the classes. The values are the corresponding class models. Can contain additional properties.
    • Additional properties: Refer to #/$defs/ArtifactResourceClass⁠.
• ArtifactResourceClass (object): Model to describe a resource class of an artifact.
  • name (string, required): The name of the metadata class.
  • description: A description of the metadata class. Default: null.
    • Any of
      • string
      • null
  • anchor_point (required): The anchor point for this metadata class. Refer to #/$defs/AnchorPoint⁠.
  • json_schema (object, required): The JSON schema for this metadata class. Can contain additional properties.

⁠Usage:

A template YAML file for configuring the service can be found at ./example_config.yaml⁠. Please adapt it, rename it to .metldata.yaml, and place it in one of the following locations:

• in the current working directory where you execute the service (on Linux: ./.metldata.yaml)
• in your home directory (on Linux: ~/.metldata.yaml)

The config YAML file will be automatically parsed by the service.

Important: If you are using containers, the locations refer to paths within the container.

All parameters mentioned in the ./example_config.yaml⁠ can also be set using environment variables or file secrets.

For naming the environment variables, just prefix the parameter name with metldata_, e.g. for the host set an environment variable named metldata_host (you may use both upper or lower cases, however, it is standard to define all env variables in upper cases).

To use file secrets, please refer to the corresponding section⁠ of the pydantic documentation.

⁠Architecture and Design:

The framework uses a combination of ETL, CQRS, and event sourcing. Currently it is designed to mostly run as a CLI application for managing metadata on the local file system. However, later, it will be translated into a microservice based-architecture.

⁠One Write and Multiple Read Representations

Instead of having just a single copy of metadata in a database that supports all CRUD actions needed by all the different user groups, we propose to follow the CQRS pattern by having one representation that is optimized for write operations and multiple use case-specific representations for querying metadata. Thereby, the write-specific representation is the source of truth and fuels all read-specific representations through an ETL process. In the following, the read-specific representations are also referred to as artifacts.

This setup with one write and multiple read representation has the following advantages: