Decizii despre SQLite, schema runtime, migrare, seed, backup/restore si sursele de adevar pentru date operationale.
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.
Decizie:
var/host-manager.sqlite devine sursa de adevar runtime pentru registry si Work Ordersconfig/hosts.yaml si config/work-orders.yaml raman seed/snapshot/export compatibility files/download/hosts.yaml, /download/local-hosts.tsv si /download/monitoring.json sunt randate din SQLiteconfig/local-hosts.tsv ramane manifest generat explicit pentru sync-ul DNS localvar/Scop:
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.
Decizie:
hosts.fqdn devine cheia reala pentru hosturi, ca numele complete sa evite coliziuni intre domeniilegacy_id ramane doar compatibilitate pentru UI/API-ul curenthost_aliases, inclusiv dupa retragerevhosts si pot fi mutate prin schimbarea host_fqdnhostsdata_workers, dhcp_leases si mdns_observationscertificates si certificate_dns_namesdocuments ramane doar tabel legacy pentru migrare din modelul vechi document-storeScop:
hosts