Hostea architecture evolution


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.

  • is delegated to it is an Enough instance that runs a single host for the DNS
  • 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/
  • create the VM xxx-host and obtain the IP
  • configure to delegate 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/ file tree
  • remove the DNS delegation from

These actions are triggered by the CI using a repository that contains ~/.enough (instead of ~/.enough/ The CI script ( 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/ file:
    • new => run host create xxx-host => host_exists
    • host_exists => configure to delegate to xxx-host IP => host_ready
    • host_ready => run host service create gitea => service_ready
    • host_delete => host delete xxx-host & backups + unconfigure delegation => host_deleted
    • host_deleted => rm ~/.enough/ 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.