Internal Data Model

Backwards compatibility, during minor version upgrades, can be broken due to changes in the relations data.

This document is intended only for charm developers.

We aim to document the internal data models currently used in order to carefully assess any breaking changes in future releases of the OpenSearch charm.

We distinguish between the different types of relations.

1. Peer relation:

a. Application data:

• Generic:

  • Relation endpoint: opensearch-peers:
  • Content:
    • security_index_initialised: bool: whether the security index has been initialized through the opensearch securityadmin script.
    • admin_user_initialized: bool: indicates that the admin user has been created and set.
    • bootstrap_contributors_count: int:
    • nodes_config: List[Node]: full list of current nodes configured by the charm.
      • to be deprecated - once confirmed opensearch is able to make an election with an even number of cm eligible nodes
    • deployment_description: DeploymentDescription: description of the current deployment.
    • update-ts: int: current time in nanoseconds since epoch (used to trigger a peer-rel-changed event by the leader).
      • to be deprecated in favor of the same flag in unit data

• On large deployments:

  • Relation endpoint: opensearch-peers
  • Content:
    • cluster_fleet_apps: PeerClusterFleetApps: Mapping of full application id and PeerClusterApp (full descriptor of a juju opensearch app)

• Locking (rolled operations):

  • Relation endpoint: node-lock-fallback
  • Content:
    • unit-with-lock: str: full name of the unit holding the lock, when peer relation is used for locking.
    • leader-acquired-lock-after-juju-event-id: str: indicates the juju event id where unit-with-lock was set.

• Upgrades:

  • Relation endpoint: upgrade-version-a
  • Content:
    • versions: Dict[str, str] / {"charm": "", "workload": ""}: descriptor of the current charm and workload (opensearch) versions.
    • upgrade-resumed: bool: whether the upgrade procedure resumed after confirming the first unit to upgrade is healthy.
    • -unused-timestamp-upgrade-resume-last-updated: str: set current time to trigger a relation changed event.

b. Unit data:

• Generic:

  • Relation endpoint: opensearch-peers
  • Content:
    • started: bool: whether this unit has fully started and the node is up.
    • tls_configured: bool: flag set when TLS is fully configured in a unit (the TLS secrets / certificates and keys have been set and stored on disk)
    • bootstrap_contributor: bool: whether a cluster_manager eligible node has been part of the bootstrapping process (initial_cluster_managerin opensearch.yml)
    • certs_exp_checked_at: str: expiration date of the certificates (date_format %Y-%m-%d %H:%M:%S)
    • update-ts: int: current time in nanoseconds since epoch (used to trigger a peer-rel-changed event by any unit).

• Locking (rolled operations):

  • Relation endpoint: node-lock-fallback
  • Content:
    • lock-requested: bool: whether this unit requested the lock.
    • -trigger: str: set the current juju context id to trigger a rel changed event on the leader (from a non leader unit).

• Upgrades:

  • Relation endpoint: upgrade-version-a
  • Content:
    • snap_revision: str: current revision of the installed snap.
    • workload_version: str: current version of the opensearch workload.
    • state: UnitState: current state of the upgraded/upgrading unit (healthy, restarting, upgrading, outdated)