[#769] retire questions files — open items ticketed in Redmine (NeedsInput)
v10/v11 archived under archive/questions/; carried opens mapped to tickets #800-#807. https://projects.knownelement.com/issues/769
This commit is contained in:
@@ -0,0 +1,120 @@
|
||||
# Questions — v10 (current round)
|
||||
|
||||
New round: O&M lane repo split + change management (work order 2026-09-03,
|
||||
[#769](https://projects.knownelement.com/issues/769)). Still-open PMG items
|
||||
from v9 carried at the bottom. One-line answers fine.
|
||||
|
||||
## Done while you were away (no answers needed — for the 20-min sitting)
|
||||
|
||||
- PFVCluster split into 12 dedicated KNEL repos (`~/projects/KNEL/<repo>`),
|
||||
each with Redmine ticket + Discourse topic + git history. Map:
|
||||
[t/296](https://community.turnsys.com/t/296) + AGENTS.md. PFVCluster keeps
|
||||
cluster content only; KNELIAC references the new repos.
|
||||
- Unit tests moved with code (netinfra, facilities) and pass. All repos
|
||||
carry the enforcement layer; pre-push audits green.
|
||||
- Change management: prod/preprod/sectestbed env map from live tsys5 state +
|
||||
snapshot lifecycle tool (`scripts/pve-snapshot.sh`, verified end-to-end on
|
||||
throwaway VM 59999, destroyed same session) — [t/331](https://community.turnsys.com/t/331).
|
||||
Audit log: t/298 reply #120. pfv-bms/netinfra/PMG/PBS hard-protected in the tool.
|
||||
|
||||
## O&M round — new (one decision each)
|
||||
|
||||
**OQ1 (repo visibility).** Created all 12 repos PUBLIC per the 2026-08-31
|
||||
ruling, matching PFVCluster's class. OK, or flip some/all private
|
||||
(one-click each; say which)?
|
||||
|
||||
A: public is fine
|
||||
|
||||
**OQ2 (legacy overlaps).** Old repos `TSYS-CA` and `KNELSecretsManager`
|
||||
overlap the new `ca` / `secrets`. Archive them into the new scheme
|
||||
(redirect README), or leave as-is?
|
||||
|
||||
A; port them both to the new respective repository as it makes sense
|
||||
|
||||
**OQ3 (apt-satellite design).** Recommend: start with a flat pinned-mirror
|
||||
(the #758 tsys-ca pattern), graduate to aptly when the fleet grows.
|
||||
Approve?
|
||||
|
||||
Yes
|
||||
|
||||
**OQ4 (Prometheus placement).** Recommend: Prometheus + Alertmanager on
|
||||
tsys-librenms alongside LibreNMS (same vantage, no new VM); Grafana stays
|
||||
on Cloudron. Approve, or name a host?
|
||||
|
||||
No. Stay on cloudron.
|
||||
|
||||
**OQ5 (Kuma window automation).** `~/.creds/uptime-kuma.env` exists — may I
|
||||
wire it into `pve-snapshot.sh` so rollbacks auto-create the maintenance
|
||||
window (and close it after), instead of the current manual reminder?
|
||||
|
||||
Yes
|
||||
|
||||
**OQ6 (preprod ownership).** The 531xx preprod lane on tsys5: is THIS lane
|
||||
the driver for vendor-version soak (~1wk, then promote), with per-domain
|
||||
chats consulted? Or per-stack?
|
||||
|
||||
Hmmm. Not sure. I think this lane we map it out and test . And develop the proxsss and run the promotions / soak per stack . Analyze and report / retort please.
|
||||
|
||||
**OQ7 (GLPI changes during converge loops).** Until GLPI change-control is
|
||||
ruled (#705/#741): sectestbed playbook iterations stay Redmine-ticket-only,
|
||||
exception requests noted in the ticket. OK, or start logging GLPI Changes
|
||||
now?
|
||||
|
||||
Start now
|
||||
|
||||
**OQ8 (pfv-bms → KNELBMS rename).** Deferred per your golden rule (HA chat
|
||||
active). Confirm the rename lands with the HA chat once you bless it — this
|
||||
lane will not touch it.
|
||||
**A (founder, 2026-09-04, HA session): APPROVED — going ahead.** "I am
|
||||
planning to tell all the other KNEL repos in their respective chats to
|
||||
reference KNELBMS as the gold standard for SDLC/CI/CD/prod stability,
|
||||
enterprise grade reliability." Execution plan: #785 (staged; repo → VM →
|
||||
DNS, aliases kept through soak). Awaiting: gitea token/API for the repo
|
||||
rename + founder confirm on full scope (repo-only vs repo+VM+hostname+DNS).
|
||||
|
||||
## Carried from v9 — still open (PMG, #696)
|
||||
|
||||
**PQ5 (native PMG cluster?).** Recommended: yes — config + quarantine
|
||||
replication between .1.11/.1.10, managed strictly serial. OK?
|
||||
|
||||
Yes.
|
||||
|
||||
**PQ6 (TLS from fleet CA #697?).** Recommended: yes for the two admin
|
||||
UIs; SMTP stays opportunistic.
|
||||
|
||||
Yes
|
||||
|
||||
**PQ7 (notify address).** Confirm `coo@turnsys.com` for PMG alerts +
|
||||
held-mail notices?
|
||||
|
||||
Yes . For all root and postmaster etc mail
|
||||
|
||||
**PQ8 (VIP specifics).** Confirm VIP 192.168.3.249 + `smtp.knel.net` +
|
||||
dhcpd host-decl pin (VRRP MAC 00:00:5e:00:01:0a)?
|
||||
|
||||
Yea
|
||||
|
||||
**PQ9 (outbound cutover staging).** Serial staged: PVE hosts + PBS first
|
||||
(verify a week), then VM postfix. OK?
|
||||
|
||||
Yes
|
||||
|
||||
**PQ11 (Cloudron relay user — founder side).** Create `pfv-relay@turnsys.com`
|
||||
for PMG submission, or point me at who does? Fallback: PMG delivers direct
|
||||
to recipient MXs.
|
||||
|
||||
**PQ12 (k8s submission port).** :25 unauthenticated from trusted LAN as
|
||||
default; :587+auth later if wanted. OK?
|
||||
|
||||
Yes
|
||||
|
||||
**PQ10 (side findings — ticket placement).** (a) tsys-ucs-02 root alias
|
||||
blackhole; (b) Wazuh alerting never configured (#335). Ride-alongs in #696
|
||||
or separate sub-tickets?
|
||||
|
||||
As you wish. I don’t have an option either way. Get outbound mail working everywhere.
|
||||
|
||||
## Carried from v6 — still open
|
||||
|
||||
**Q4. Second human approver in gitea?** Blocks access-roster merges by
|
||||
design until landed. Does not block code/deploy work.
|
||||
@@ -0,0 +1,21 @@
|
||||
# Questions — v11 (current round)
|
||||
|
||||
New round opened by the 09-04 night grind (monitoring wiring t/335 EXECUTED;
|
||||
apt-satellite lane LIVE; CA/ACME pilot done). Two gating questions for the
|
||||
next phase. One-line answers fine. (v10 + history: archive/questions/)
|
||||
|
||||
## CA/ACME phase B (t/327 design)
|
||||
|
||||
**Q1 (DNS-01 for the fleet ACME).** The prod ACME endpoint on tsys-ca (phase
|
||||
B) needs to validate knel.net identifiers. Recommended: **DNS-01 via
|
||||
Technitium** — may I generate a TSIG key scoped to `_acme-challenge.*`
|
||||
updates and load it on tsys-dns (one config edit + git SoR sync), or prefer
|
||||
HTTP-01 only for now?
|
||||
|
||||
A: approved
|
||||
|
||||
**Q2 (step-ca go on tsys-ca).** Deploy the prod ACME container on the tsys-ca
|
||||
VM (new container, intermediate signed by the existing fleet root, bound to
|
||||
the Tailscale IP :8443) — approve to start, or pick a window?
|
||||
|
||||
A: approved.
|
||||
Reference in New Issue
Block a user