Newer
■
■
■
■
■
■
■
■
■
■
Older
59 lines
|
3.261kb
| 1 |
# Database Development Log |
|
| 2 | ||
| 3 |
Decizii despre SQLite, schema runtime, migrare, seed, backup/restore si sursele de adevar pentru date operationale. |
|
| 4 | ||
| 5 |
## 2026-06-09 - SQLite Runtime Source of Truth |
|
| 6 | ||
| 7 |
Observatie: editarile de hosts facute in aplicatia live puteau ramane in working tree-ul de pe jumper sau puteau fi suprascrise/confuzionate la push-ul de cod. Modelul vechi descria simultan `config/hosts.yaml` ca registry editabil in git si ca data operationala runtime, ceea ce nu era o sursa de adevar clara. |
|
| 8 | ||
| 9 |
Decizie: |
|
| 10 | ||
| 11 |
- `var/host-manager.sqlite` devine sursa de adevar runtime pentru registry si Work Orders |
|
| 12 |
- `config/hosts.yaml` si `config/work-orders.yaml` raman seed/snapshot/export compatibility files |
|
| 13 |
- la prima pornire, aplicatia seed-uieste documentele lipsa din YAML in SQLite |
|
| 14 |
- download-urile `/download/hosts.yaml`, `/download/local-hosts.tsv` si `/download/monitoring.json` sunt randate din SQLite |
|
| 15 |
- `config/local-hosts.tsv` ramane manifest generat explicit pentru sync-ul DNS local |
|
| 16 |
- push-urile de cod catre jumper nu trebuie sa inlocuiasca baza runtime din `var/` |
|
| 17 | ||
| 18 |
Scop: |
|
| 19 | ||
| 20 |
- editarile facute in UI sa nu se piarda la deploy/push de cod |
|
| 21 |
- sa existe o singura autoritate runtime |
|
| 22 |
- YAML/TSV sa ramana utile pentru export, review si bootstrap fara sa fie storage-ul live |
|
| 23 | ||
| 24 |
## 2026-06-09 - Relational Runtime Schema |
|
| 25 | ||
| 26 |
Observatie: primul pas SQLite mutase sursa de adevar din git in baza de date, dar o pastra ca document YAML intr-o tabela generica. Asta rezolva pierderea editarilor la push, dar nu oferea o baza de date operationala reala. |
|
| 27 | ||
| 28 |
Decizie: |
|
| 29 | ||
| 30 |
- `hosts.fqdn` devine cheia reala pentru hosturi, ca numele complete sa evite coliziuni intre domenii |
|
| 31 |
- `legacy_id` ramane doar compatibilitate pentru UI/API-ul curent |
|
| 32 |
- aliasurile sunt pastrate in `host_aliases`, inclusiv dupa retragere |
|
| 33 |
- vhosturile sunt in `vhosts` si pot fi mutate prin schimbarea `host_fqdn` |
|
| 34 |
- rolurile, sursele, flagurile si SSH sunt in tabele separate, nu coloane adaugate continuu in `hosts` |
|
| 35 |
- workerii de date au `data_workers`, `dhcp_leases` si `mdns_observations` |
|
| 36 |
- certificatele emise au `certificates` si `certificate_dns_names` |
|
| 37 |
- `documents` ramane doar tabel legacy pentru migrare din modelul vechi document-store |
|
| 38 | ||
| 39 |
Scop: |
|
| 40 | ||
| 41 |
- schema sa poata sustine inventar, DNS, vhosturi, observatii externe si certificate fara sa piarda istoric operational |
|
| 42 |
- aliasurile/vhosturile retrase sa ramana audibile in baza de date |
|
| 43 |
- structura sa fie extensibila fara sa supraincarce tabelul `hosts` |
|
| 44 | ||
| 45 |
## 2026-06-10 - DHCP Lease Push Collector |
|
| 46 | ||
| 47 |
Observatie: DHCP-ul de pe `192.168.2.1` este autoritatea pentru alocarea IP-urilor LAN, dar baza runtime avea doar tabela `dhcp_leases`, fara un colector operational. |
|
| 48 | ||
| 49 |
Decizie: |
|
| 50 | ||
| 51 |
- MikroTik impinge evenimentele de lease prin `lease-script` catre `POST /api/collect/dhcp-leases` |
|
| 52 |
- endpoint-ul este protejat cu `HOST_MANAGER_DHCP_PUSH_TOKEN`, separat de sesiunea OTP pentru UI |
|
| 53 |
- ingest-ul scrie doar in `dhcp_leases` si actualizeaza workerul `dhcp-router` |
|
| 54 |
- observatiile DHCP raman material de audit/propunere si nu modifica automat host registry-ul sau manifestul DNS |
|
| 55 | ||
| 56 |
Scop: |
|
| 57 | ||
| 58 |
- sa colectam lease-uri fara credential SSH pentru router in aplicatie |
|
| 59 |
- sa pastram DHCP ca sursa observata cu prioritate mare, dar fara side effect automat asupra DNS-ului local |