A catalogue of opinionated and standardized interface specifications for charmed operator relations. The purpose of the repository is to outline the behavior and requirements for key interface names, ensuring that charms claiming to implement a certain interface actually are capable of being integrated with each other.
To contribute a new interface specification, open a pull request containing:
- a
README.md
explaining the purpose of the interface and the protocol - a
schema.py
file containing pydantic models that specify the app and unit databag model for either side of the interface. charms.yaml
file consisting of a list of anyproviders
andrequirers
known to adhere to the specification.- under
docs/
, the json schemas generated from the pydantic schemas. You can use commandtox -e build-json-schemas
to generate them automatically. Do not edit those files manually.
To quickly get started, see the template interface for a template of what to include and how it should be structured.
Category | Interface | Status |
---|---|---|
Data | mysql_client |
|
postgresql_client |
||
mongodb_client |
||
kafka_client |
||
opensearch_client |
||
database_backup |
||
Identity | oauth |
|
Observability | grafana_auth |
|
ingress |
||
ingress_per_unit |
||
prometheus_remote_write |
||
prometheus_scrape |
||
Networking | ingress |
|
ingress_per_unit |
||
Security | mutual_tls |
|
tls_certificates/v0 |
||
tls_certificates/v1 |
||
Storage | s3 |
Category | Interface | Status |
---|---|---|
Metadata | k8s-service |
Category | Interface | Status |
---|---|---|
Identity | hydra_endpoints |
|
kratos_external_idp |
||
kratos_endpoints |
For a more detailed explanation of statuses and how they should be used, see the legend.