Endpoint

See also: Application

In Juju, an endpoint (or application endpoint) is used to connect to another application’s endpoint in order to form an integration (relation). An endpoint is defined in a charm’s metadata.yaml by the collection of three properties: a role, a name, and an interface.

There are three types of roles:

  • requires: The endpoint can optionally make use of services represented by another charmed operator’s endpoint over the given interface.
  • provides: The endpoint represents a service that another charmed operator’s endpoint can make use of over the given interface.
  • peers: The endpoint can coexist with another charmed operator’s endpoint in a peer-to-peer manner (i.e. only between units of the same application). This role is often used in a cluster or high availability context.

The three types of endpoint roles are illustrated below.

Endpoint_types

For example, the pertinent excerpt of the metadata.yaml file for the wordpress charm is as follows:

requires:
  db:
    interface: mysql
  nfs:
    interface: mount
  cache:
    interface: memcache
provides:
  website:
    interface: http
peers:
  loadbalancer:
    interface: reversenginx

Here, there are three requires endpoints (db, nfs, and cache), one provides endpoint (website), and one peers endpoint (loadbalancer). For instance, we can say that “the db endpoint can make use of services offered by another charm over the mysql interface”. These endpoints and interfaces can be illustrated as follows:

Despite the term requires, the three cited endpoints are not hard requirements for the wordpress charm. You will need to read the charm’s entry on Charmhub (e.g. wordpress) to discover actual requirements as well as how the charm works. For instance, it is not obvious that the wordpress charm comes bundled with an HTTP server (nginx), making a separate HTTP-based charm not strictly necessary.

Peer integrations happen automatically and do not need to be specified with the juju integrate command.

Just a note to consider changing “relation” to “integration” and then link to its page.

I feel it would also help clarify things to say a few words on what is meant by an “interface”. Something like:

An interface is a protocol that can be implemented across the charm ecosystem. When two charms each have an endpoint that supports a common interface they are able to auto-negotiate a connection. This connection is called an integration.

I think the last diagram is not quite correct because the peer integration with interface reversenginx is drawn between different applications (C and D). As I understand it, peer integrations can only exist between units of the same application.

1 Like

@tmihoc ^^^

2 Likes