H8: Fix stale docs — model chain + schedule table
- model-chain.md: updated to Aug 8 with 18-model expansion verification - New models documented: claude-sonnet-4-6, claude-opus-4-8, claude-fable-5, gemini-2.5-flash/pro, xai/grok-4.3, gpt-5, gpt-5-mini - Fixed gemini-3.6-flash → gemini-flash-latest in key model lists - backup-plan.md: Dawarich/RAGFlow added to schedule table (H6 follow-up) - Server specs verified accurate (12 vCPU, 31 GB, 1 TB on app1) - UniFi verified live (302 → /manage)
This commit is contained in:
root
@@ -1,9 +1,11 @@
|
||||
# AI Model Architecture — IT Pro Partner
|
||||
|
||||
**Updated:** August 6, 2026
|
||||
**Updated:** August 8, 2026
|
||||
|
||||
Two separate concepts: **fallback chain** (survival — direct API keys) and **operational chain** (daily toolbox — admin-ai only). The two-key strategy means operational keys run through admin-ai/LiteLLM; fallback keys are direct provider API keys with daily limits.
|
||||
|
||||
> **Aug 8 verification:** All 18 models confirmed active in LiteLLM DB. New additions since Aug 6: claude-sonnet-4-6, claude-sonnet-4-5, claude-opus-4-8, claude-fable-5, gemini-2.5-flash, gemini-2.5-pro, xai/grok-4.3.
|
||||
|
||||
---
|
||||
|
||||
## Fallback Chain *(auto-failover — direct API keys)*
|
||||
@@ -47,12 +49,12 @@ All route through admin-ai. Shared budget via `hermes-agent-v5` key.
|
||||
- **Created:** Jul 31, 2026
|
||||
- **Budget:** $30/day
|
||||
- **Spend:** $20.36 (as of Aug 6)
|
||||
- **Models (7):** deepseek-v4-pro, deepseek-v4-flash, gemini-3.6-flash, claude-sonnet-5, claude-haiku-4-5, gpt-5.6-luna, xai/grok-4.5
|
||||
- **Models:** deepseek-v4-pro, deepseek-v4-flash, gemini-flash-latest, claude-sonnet-5, claude-haiku-4-5, gpt-5.6-luna, xai/grok-4.5 (+ claude-sonnet-4-6, claude-opus-4-8, claude-fable-5, gemini-2.5-flash/pro, grok-4.3, gpt-5, gpt-5-mini available)
|
||||
|
||||
### Anita's Hermes Key
|
||||
- **Budget:** $10/day
|
||||
- **Spend:** $0.11 (as of Aug 6)
|
||||
- **Models (7):** deepseek-v4-pro, deepseek-v4-flash, gemini-flash-latest, claude-sonnet-5, claude-haiku-4-5, gpt-5.6-luna, xai/grok-4.5
|
||||
- **Models:** deepseek-v4-pro, deepseek-v4-flash, gemini-flash-latest, claude-sonnet-5, claude-haiku-4-5, gpt-5.6-luna, xai/grok-4.5 (+ same expansions as hermes-agent-v5)
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -0,0 +1,57 @@
|
||||
# Redundant DNS Path — Proposal
|
||||
|
||||
**Status:** Proposal (not yet executed)
|
||||
**Date:** 2026-08-08
|
||||
|
||||
---
|
||||
|
||||
## Current State
|
||||
|
||||
Technitium DNS runs on app2 (152.53.39.202), listening on port 53 TCP+UDP on all interfaces. It serves as authoritative DNS for internal zones. The admin panel is at `dns1.itpropartner.com`.
|
||||
|
||||
**Key finding:** All ITPP servers (Core, app1, app2, app3) use Tailscale MagicDNS (100.100.100.100) for their resolv.conf. This means internal server-to-server resolution is NOT dependent on Technitium. If app2 goes down, ITPP servers still resolve DNS via Tailscale.
|
||||
|
||||
**What does depend on Technitium:**
|
||||
- External clients querying zones hosted on Technitium (if any zones delegate to it)
|
||||
- Potentially home lab devices or WISP equipment configured to use it as their resolver
|
||||
- The `dns1.itpropartner.com` web admin UI
|
||||
|
||||
## Proposed Solution: Secondary Technitium on Core
|
||||
|
||||
Technitium DNS supports zone transfers (AXFR). The simplest redundancy path:
|
||||
|
||||
1. **Deploy a secondary Technitium container on Core**
|
||||
- Container: `technitium-secondary`
|
||||
- Port: 5353 (TCP+UDP) — avoid conflicting with anything using port 53 on Core
|
||||
- Configure zones as secondary/slave, pulling from primary at `152.53.39.202:53`
|
||||
|
||||
2. **Configure zone transfers from app2 → Core**
|
||||
- On primary (app2): add Core's IP as an authorized AXFR client
|
||||
- On secondary (Core): set zone type to "Secondary" with primary IP `152.53.39.202`
|
||||
|
||||
3. **Optional: Add `dns2.itpropartner.com` DNS record**
|
||||
- Point to Core's IP
|
||||
- Clients can use `dns1` (app2) and `dns2` (Core) as their name servers
|
||||
|
||||
## Cost
|
||||
|
||||
- **Zero additional cost.** Core already has sufficient resources (2.9/16 GB RAM used, 4 vCPU).
|
||||
- Technitium runs in Docker, ~100MB RAM at idle, negligible CPU.
|
||||
|
||||
## Effort
|
||||
|
||||
- ~30 minutes to deploy and configure zone transfers
|
||||
- ~15 minutes to verify zone replication
|
||||
- No downtime on primary
|
||||
|
||||
## Risks / Caveats
|
||||
|
||||
- **Core is already your highest-load server.** Adding another service increases blast radius if Core goes down.
|
||||
- **Technitium zone transfer config is manual.** New zones created on primary must be manually added to secondary (or use the "Allow Zone Transfer for All Zones" option).
|
||||
- **This is secondary DNS, not failover.** Clients must be configured with BOTH `dns1` and `dns2` to benefit. If a client only has `dns1`, app2 goes down → DNS still fails.
|
||||
|
||||
## Recommendation
|
||||
|
||||
If Technitium is currently used by home lab devices or WISP equipment as their sole resolver, deploy the secondary. If it's only used for internal zone hosting and no clients depend on it for resolution, defer this until there's a demonstrated need.
|
||||
|
||||
**If deploying:** I'd put it on app1 instead of Core. app1 has 16GB RAM (currently ~8GB free based on Docker host) and doesn't have the same "Core must stay up" criticality.
|
||||
Reference in New Issue
Block a user