# Bind charm architecture The following diagram shows the different modules of this charm and how they interact with each other. ## Scaling behavior When Bind is scaled, only one unit gets the `active` status, all the others are in `standby`. A new `active` unit is elected whenever the previous one goes down.
\\\\ The `active` unit updates the zone configuration of its workload and has Bind working as a primary authoritative server over them.
\\\\ All the `standby` units have Bind working as a secondary server, replicating the records via the usual DNS zone transfer. ## Charm code overview The `src/charm.py` is the default entry point for a charm and has the `BindCharm` Python class which inherits from `CharmBase`. `CharmBase` is the base class from which all charms are formed, defined by [Ops](https://documentation.ubuntu.com/ops/latest/) Python framework for developing charms. #### SEE ALSO See more in the Juju docs: [Charm](https://canonical.com/juju/docs/juju-cli/3.6/reference/charm/#charm) ## Workload The workload of this charm is a snap whose source code is in the `charmed-bind` directory of the [dns-operators repository](https://github.com/canonical/dns-operators). The workload is operated through the `src/bind.py` module which is able to set up, start, stop, restart, and change the workload configuration files.
\\\\ The workload doesn’t communicate with the charm. It merely executes the charm’s orders.
\\\\ Outside of the snap, the charm also sets up a systemd timer to awaken every minute through the custom event `ReloadBindEvent`. The hook responding to this event makes sure that the configuration of Bind is up to date with the charm’s relations.