refactor(inventory): address the PVE nodes by name, not by IPv4 literal #472

2026-08-07T17:45:19Z

claude-bot commented

2026-08-07 17:45:19 +00:00

jupiter, neptune and saturn were the last entries in pve_hosts.yml still reached via ansible_host=<IPv4 literal>. Every other host in that file — authentik, netbird, proxy, nas-1, grafana, edge-1 — has always used its FQDN. These three were the outlier, not the convention.

An address in an inventory is allocator state standing in for identity, and it pins access to the legacy family: the names resolve IPv6-first, which is the primary path on this network. DNS is authoritative for where a host is; the inventory should say which host.

The short inventory_hostname is kept deliberately — plays key on it (ntp_servers[inventory_hostname] in install-ntp-ha.yml, node names in opentofu, the prometheus targets) — so only ansible_host changes.

What this does NOT claim

An earlier draft of this change justified itself with the connection stalls seen while applying the NTP work on 2026-08-07. That attribution was wrong and has been removed. Those stalls were the IPS reacting to the connection pattern I was generating — a port sweep across 22/9100/12345/3000, then rapid repeated SSH across hosts interleaved with Ansible's own connection churn — not an address-family problem. The same hosts answered fine a minute later, which is the signature of rate-limiting, not routing.

This change stands on convention and on not encoding a lease as identity. Nothing more.

claude-ws left alone

Its comment documents that obg.renner.uno is split-horizon and resolves to the public proxy from home. That explains why that particular name is unusable — not why an address literal is right. A name that resolves to the wrong target calls for a name that resolves to the right one; the comment's own remedy ("switch to the stable Netbird mesh IP") is another literal described as stable.

Out of scope here, and I don't know whether a suitable internal record exists.

Verification

The three nodes were reached by name throughout the NTP rollout that followed this change, and all three carry the expected config:

jupiter    allow 10.2.0.0/16 allow fd00::/8 allow fe80::/10
neptune    allow 10.2.0.0/16 allow fd00::/8 allow fe80::/10
saturn     allow 10.2.0.0/16 allow fd00::/8 allow fe80::/10

🤖 Generated with Claude Code

`jupiter`, `neptune` and `saturn` were the last entries in `pve_hosts.yml` still reached via `ansible_host=<IPv4 literal>`. Every other host in that file — authentik, netbird, proxy, nas-1, grafana, edge-1 — has always used its FQDN. These three were the outlier, not the convention. An address in an inventory is allocator state standing in for identity, and it pins access to the legacy family: the names resolve IPv6-first, which is the primary path on this network. DNS is authoritative for *where* a host is; the inventory should say *which* host. The short `inventory_hostname` is kept deliberately — plays key on it (`ntp_servers[inventory_hostname]` in `install-ntp-ha.yml`, node names in opentofu, the prometheus targets) — so only `ansible_host` changes. ## What this does NOT claim An earlier draft of this change justified itself with the connection stalls seen while applying the NTP work on 2026-08-07. **That attribution was wrong and has been removed.** Those stalls were the IPS reacting to the connection pattern I was generating — a port sweep across 22/9100/12345/3000, then rapid repeated SSH across hosts interleaved with Ansible's own connection churn — not an address-family problem. The same hosts answered fine a minute later, which is the signature of rate-limiting, not routing. This change stands on convention and on not encoding a lease as identity. Nothing more. ## claude-ws left alone Its comment documents that `obg.renner.uno` is split-horizon and resolves to the public proxy from home. That explains why *that particular name* is unusable — not why an address literal is right. A name that resolves to the wrong target calls for a name that resolves to the right one; the comment's own remedy ("switch to the stable Netbird mesh IP") is another literal described as stable. Out of scope here, and I don't know whether a suitable internal record exists. ## Verification The three nodes were reached by name throughout the NTP rollout that followed this change, and all three carry the expected config: ``` jupiter allow 10.2.0.0/16 allow fd00::/8 allow fe80::/10 neptune allow 10.2.0.0/16 allow fd00::/8 allow fe80::/10 saturn allow 10.2.0.0/16 allow fd00::/8 allow fe80::/10 ``` 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit 2026-08-07 17:45:20 +00:00

refactor(inventory): address the PVE nodes by name, not by IPv4 literal

ci/woodpecker/pr/pr-review Pipeline was successful

Details

ci/woodpecker/pr/ci-scripts-test Pipeline was successful

Details

ba369a37b0

jupiter, neptune and saturn were the last entries in pve_hosts.yml still
reached via ansible_host=<IPv4 literal>. Every other host here --
authentik, netbird, proxy, nas-1, grafana, edge-1 -- has always used its
FQDN, so these three were the outlier rather than the convention.

An address in an inventory is allocator state standing in for identity, and
it pins access to the legacy family: the names resolve IPv6-first, which is
the primary path on this network. DNS is authoritative for where a host is;
the inventory should say which host.

The short inventory_hostname is kept deliberately -- plays key on it
(ntp_servers[inventory_hostname] in install-ntp-ha.yml, node names in
opentofu, the prometheus targets) -- so only ansible_host changes.

No claim that this fixes the connection stalls seen while applying the NTP
work on 2026-08-07. Those were the IPS reacting to the connection pattern I
was generating (a port sweep, then rapid repeated SSH across hosts
interleaved with Ansible's own churn), not an address-family problem. This
change stands on convention and on not encoding a lease as identity.

claude-ws is left alone: its comment documents that obg.renner.uno is
split-horizon and resolves to the public proxy from home. That explains why
that particular name is unusable, not why a literal is right -- a name that
resolves to the wrong target calls for one that resolves correctly. Out of
scope here, and I do not know whether such a record exists.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

review-bot reviewed

2026-08-07 17:47:51 +00:00

review-bot left a comment

🤖 Automated review — model claude-haiku-4-5-20251001 (complexity: trivial), commit ba369a37b00d48337448c6b11d645ed73f0f448c.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.

Summary

This PR refactors the Proxmox inventory to address three PVE nodes (jupiter, neptune, saturn) by FQDN instead of IPv4 literals, aligning them with the rest of the inventory's naming convention. The change is sound and has been verified to work in the NTP rollout that followed. No blocking issues.

🔴 Blocking

None.

🟡 Suggestions

Inconsistent Prometheus configuration (ansible/roles/prometheus-server/templates/prometheus.yml.j2)

The prometheus configuration templates still hardcode IPv4 addresses for these same nodes:

Lines 54-56: PVE API targets (10.2.40.201/202/203)
Lines 138-140: Chrony exporter targets (10.2.40.201/202/203)

These templates are rendered by the prometheus-server role during installation. While DNS resolution will correctly map the FQDNs to these IPs (so Ansible connectivity works), prometheus scraping targets are now inconsistent with the inventory's naming scheme. The prometheus.yml.j2 template should be updated to use jupiter.renner.uno, neptune.renner.uno, saturn.renner.uno instead of hardcoded IPs.

Similarly, ansible/roles/prometheus-server/templates/nodes.yml.j2 (lines 10-26) has hardcoded node exporter targets for the same three hosts and should also be updated for consistency.

This is a maintainability concern rather than a functional issue (DNS resolution ensures everything works), but updating these would complete the refactor and avoid divergence between identity (the inventory) and reachability (prometheus scraping rules).

Documentation reference (ansible/roles/claude-workstation/RUNBOOK.md)

Line 122 references the IPv4 address 10.2.40.201 in a kubeconfig setup command. This should be updated to use the FQDN (jupiter.renner.uno) or a stable IP alias for consistency with the new naming scheme (though the hardcoded IP still works for this documentation).

🟢 Nits

The new comment block in pve_hosts.yml is clear and well-reasoned. The distinction between inventory_hostname (short name, used by plays) and ansible_host (connection identity, changed here) is correctly explained.

Tests

The PR body documents manual verification: "The three nodes were reached by name throughout the NTP rollout that followed this change, and all three carry the expected config." This is operational testing and confirms connectivity works. The repo does not appear to have automated tests for inventory addressing, which is typical for infrastructure repos. No test gaps.

Recommendation

Looks reasonable — no blocking issues; suggestions above are optional refinements for consistency and maintainability.

🤖 **Automated review** — model `claude-haiku-4-5-20251001` (complexity: trivial), commit `ba369a37b00d48337448c6b11d645ed73f0f448c`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary This PR refactors the Proxmox inventory to address three PVE nodes (jupiter, neptune, saturn) by FQDN instead of IPv4 literals, aligning them with the rest of the inventory's naming convention. The change is sound and has been verified to work in the NTP rollout that followed. No blocking issues. ## 🔴 Blocking None. ## 🟡 Suggestions **Inconsistent Prometheus configuration** (`ansible/roles/prometheus-server/templates/prometheus.yml.j2`) The prometheus configuration templates still hardcode IPv4 addresses for these same nodes: - **Lines 54-56**: PVE API targets (10.2.40.201/202/203) - **Lines 138-140**: Chrony exporter targets (10.2.40.201/202/203) These templates are rendered by the prometheus-server role during installation. While DNS resolution will correctly map the FQDNs to these IPs (so Ansible connectivity works), prometheus scraping targets are now inconsistent with the inventory's naming scheme. The prometheus.yml.j2 template should be updated to use `jupiter.renner.uno`, `neptune.renner.uno`, `saturn.renner.uno` instead of hardcoded IPs. Similarly, `ansible/roles/prometheus-server/templates/nodes.yml.j2` (lines 10-26) has hardcoded node exporter targets for the same three hosts and should also be updated for consistency. This is a maintainability concern rather than a functional issue (DNS resolution ensures everything works), but updating these would complete the refactor and avoid divergence between identity (the inventory) and reachability (prometheus scraping rules). **Documentation reference** (`ansible/roles/claude-workstation/RUNBOOK.md`) Line 122 references the IPv4 address `10.2.40.201` in a kubeconfig setup command. This should be updated to use the FQDN (`jupiter.renner.uno`) or a stable IP alias for consistency with the new naming scheme (though the hardcoded IP still works for this documentation). ## 🟢 Nits The new comment block in `pve_hosts.yml` is clear and well-reasoned. The distinction between `inventory_hostname` (short name, used by plays) and `ansible_host` (connection identity, changed here) is correctly explained. ## Tests The PR body documents manual verification: "The three nodes were reached by name throughout the NTP rollout that followed this change, and all three carry the expected config." This is operational testing and confirms connectivity works. The repo does not appear to have automated tests for inventory addressing, which is typical for infrastructure repos. No test gaps. ## Recommendation Looks reasonable — no blocking issues; suggestions above are optional refinements for consistency and maintainability.

k.renner merged commit 332950b564 into master

2026-08-07 17:49:06 +00:00

k.renner referenced this issue from a commit

2026-08-07 17:49:07 +00:00

Merge pull request 'refactor(inventory): address the PVE nodes by name, not by IPv4 literal' (#472) from inventory-pve-hostnames into master

claude-bot referenced this issue from a commit

2026-08-07 17:53:02 +00:00

refactor(prometheus): address the PVE nodes by name in scrape targets

claude-bot referenced this pull request

2026-08-07 17:53:18 +00:00

refactor(prometheus): address the PVE nodes by name in scrape targets #473

Sign in to join this conversation.