Hostea architecture evolution

Bonjour,

At the moment the Hostea architecture can be summarized to be a repository containing an Enough configuration tree describing all existing instances. Since each instance is independent of the others, it would be more sensible to have one Enough configuration tree for each instance.

  • h.gna.org is delegated to bind.h.gna.org: it is an Enough instance that runs a single host for the DNS
  • xxx.h.gna.org is a single host that runs DNS, backups, reverse proxy, gitea, woodpecker as described by its own Enough instance

Creating a new instance:

  • scafold a new Enough instance file tree for ~/.enough/xxx.h.gna.org
  • create the VM xxx-host and obtain the IP
  • configure ns1.h.gna.org to delegate xxx.h.gna.org to xxx-host IP (similar to what is done for tests)
  • create the gitea/woodpecker service on xxx-host

Deleting an existing instance:

  • delete the xxx-host & all backups
  • remove the ~/.enough/xxx.h.gna.org file tree
  • remove the DNS delegation from ns1.h.gna.org

These actions are triggered by the CI using a repository that contains ~/.enough (instead of ~/.enough/h.gna.org). The CI script (hostea.sh) logic is:

  • Figure out which instance to focus on depending on the output of git stat.
  • Run action depending on the content of the ~/.enough/xxx.h.gna.org/state file:
    • new => run host create xxx-host => host_exists
    • host_exists => configure ns1.h.gna.org to delegate xxx.h.gna.org to xxx-host IP => host_ready
    • host_ready => run host service create gitea => service_ready
    • host_delete => host delete xxx-host & backups + unconfigure ns1.h.gna.org delegation => host_deleted
    • host_deleted => rm ~/.enough/xxx.h.gna.org entirely

During the normal lifetime of an instance, the state is “service_ready” most of the time and the action is run multiple times, for instance whenever there is an upgrade to be done.

Another advantage of having an independent Enough configuration for each instance is that they may be located on different OpenStack providers or libvirt hypervisors and still managed in a unified way by the CI.