Its disks were migrated to a new server (prompted by an unsolvable issue
with the previous box's network interface; might have been a mobo issue).

There's a bit of a chicken and egg situation here but it's preferable to
manage the server's attributes the same way as all of the cloud servers.

We want non-DevOps to be able to deploy project documentation (ex:
repod) with GitLab Pages and a separate domain was considered the only
sensible solution due to security issues[1].

[1] https://github.blog/2013-04-09-yummy-cookies-across-domains/

asia.mirror.pkgbuild.com has been offline for 12 days so far while we
wait for a NIC replacement. Should have taken it out of DNS NS duties
earlier but better late than never.

When adding a new geo domain or doing other testing, we would want to
use a low TTL to allow for making quick changes to the configuration.

- add the new role to redirect.archlinux.org
- release mirror.pkgbuild.com of all DNS duties

New hcloud adds protection fields to servers, volumes and floating IPs.

Gives the option to downgrade a server in the future, similar to the
default on Hetzner's Cloud Console ("CPU and RAM only").

Sven considers this location to have higher capacity and reliability.

Follow-up to [1]; while most of our cloud servers are in Helsinki, the
latency from most of Europe is lower when accessing servers in Germany.

Pinging from multiple locations using ping.pe, the latency to Nuremberg
from most locations appears to be 10-20ms lower (compared to Helsinki).

[1] !500

Kristian Klausen authored 3 years ago and Jelle van der Waa committed 3 years ago

With Hetzner now having a datacenter in the US[1], we don't want to
accidentally create a server in the US, so let's always create them in
Helsinki where most of our cloud servers are.

[1] https://www.hetzner.com/news/11-21-usa-cloud/

machine.domain has been an mandatory attribute which creates
<domain>.archlinux.org entries automagically. For migrations this can be
a problem if <domain>.archlinux.org supposed to point to a different
machine. Adding the new machine with the same domain leads to additional
DNS entries. The DNS ends up pointing to both machines in this case.
By making the domain attribute optional for machines, we allow the new
machines to be created without any domain pointing to them.

Kristian Klausen authored 4 years ago and Frederik Schwan committed 4 years ago

We need to keep the balance between automation and readability.