Acest director este punctul unic de lucru pentru proiectele cluster-level actuale si viitoare.
Workflow-ul de install, uninstall si reinstall documentat aici este bazat pe implementarea cea mai completa existenta in autoNAS.
Referinte principale:
- cluster/projects/autoNAS/README.md
- cluster/projects/autoNAS/DEVELOPMENT.md
- cluster/projects/autoNAS/scripts/install.sh
- cluster/projects/autoNAS/scripts/autonas-uninstall.sh
Observatie importanta:
- autoNAS confirma workflow-ul corect de uninstall-inainte-de-reinstall si curatare a fisierelor orfane
- autoNAS nu este inca aliniat complet la noua regula de locatie pentru comenzi operator-facing, deoarece instaleaza in prezent in /usr/local/bin
- pentru proiectele noi, regula ramane /usr/local/sbin; autoNAS trebuie tratat ca precedent functional pentru workflow, nu ca standard final de layout
Pentru claritate si evitarea coliziunilor intre proiecte, toate locatiile standard trebuie namespaced cu identificatorul de organizatie:
xdevRegula generala este:
- folosim <project-name> pentru identitatea proiectului
- folosim xdev in calea de instalare pentru fisiere interne, configuratie, date si documentatie
cluster/projects/<project-name>.cluster, pentru a reduce divergenta intre workspace-uri si duplicarea documentatiei sau scripturilor.README.mdInstalarile trebuie sa foloseasca locatii predictibile si stabile:
/usr/local/sbin/usr/local/lib/xdev/<project-name>/usr/local/share/doc/xdev/<project-name>/etc/xdev/<project-name>/etc/default/xdev-<project-name>/etc/systemd/system/var/lib/xdev/<project-name>/var/cache/xdev/<project-name> daca este necesar/var/log/xdev/<project-name>Regula practica:
- daca un operator trebuie sa ruleze comanda direct, ea merge in /usr/local/sbin
- daca fisierul este suport intern pentru proiect, el merge in /usr/local/lib/xdev/<project-name>
- daca fisierul este documentatie instalata local pentru host, el merge in /usr/local/share/doc/xdev/<project-name>
- daca fisierul reprezinta configuratie editabila, el merge in /etc/xdev/<project-name> sau /etc/default/xdev-<project-name>
- daca fisierul reprezinta stare, baza locala, lock, snapshot sau alta data operationala, el merge in /var/lib/xdev/<project-name>
Locatia standard canonica pentru scriptul de dezinstalare instalat pe host este:
/usr/local/lib/xdev/<project-name>/uninstall.shMotivatie:
- uninstall-ul este in primul rand parte din mecanismul intern de lifecycle al proiectului
- trebuie sa poata fi apelat de installer pentru cleanup automat inainte de reinstall
- trebuie versionat impreuna cu restul fisierelor interne ale proiectului
- evita aglomerarea inutila a /usr/local/sbin cu scripturi care nu sunt folosite frecvent in operare zilnica
Regula de naming:
- scriptul canonic instalat pe host se numeste uninstall.sh
- directorul proiectului da contextul complet: /usr/local/lib/xdev/<project-name>/uninstall.sh
Expunere optionala pentru operator:
- daca vrem o comanda manuala simpla si predictibila, se poate instala un wrapper sau symlink in:
- /usr/local/sbin/xdev-<project-name>-uninstall
- acest wrapper trebuie sa apeleze scriptul canonic din /usr/local/lib/xdev/<project-name>/uninstall.sh
- wrapperul din /usr/local/sbin este optional; scriptul canonic din /usr/local/lib/xdev/<project-name>/ este obligatoriu
/usr/local/lib/xdev/<project-name>/uninstall.sh./usr/local/lib/xdev/<project-name>/usr/local/share/doc/xdev/<project-name>/etc/xdev/<project-name> sau /etc/default/xdev-<project-name>/var/lib/xdev/<project-name> sau /var/cache/xdev/<project-name>uninstall -> verificare curatare -> install
Fiecare proiect nou trebuie sa includa explicit:
install care foloseste locatiile well-knownuninstall care inverseaza complet instalareaREADME.md cu:
/usr/local/lib/xdev/<project-name>/uninstall.shdaemon-reload la install si uninstallsystemctl enable --now, nu doar cu enableProiectele deja mutate sub cluster/projects/ trebuie aliniate progresiv la aceste reguli.
Prioritati:
- confirmarea unui script de uninstall pentru fiecare proiect
- standardizarea instalarii in /usr/local/sbin si /usr/local/lib/xdev/<project-name>
- eliminarea reinstalarilor facute peste fisiere existente
Problemele deja identificate si rezolvate in autoNAS, care trebuie considerate reguli pentru proiectele viitoare:
daemon-reloadenabled; se foloseste enable --now pentru a evita deploy-uri cu servicii instalate dar neporniteFluxul validat de autoNAS este:
detect previous install -> run original uninstall -> clean orphan files -> install new version -> preserve user data where required
Cand se modifica un proiect existent sau se adauga unul nou, se actualizeaza si documentatia proiectului astfel incat procedura de:
sa fie explicita, repetabila si fara artefacte ramase pe host.
Pentru rollout final pe cluster nu facem deploy nod cu nod manual daca proiectul este destinat cluster-wide.
Regula practica este:
- fiecare proiect trebuie sa pastreze si varianta pe un singur nod pentru development si testing
- pentru rollout cluster-wide se foloseste orchestratorul comun din radacina:
- cluster/scripts/deploy-project.sh <project-name>
Sursa de adevar pentru noduri:
- cluster/cluster-context/madagascar.json
Exemple:
./scripts/deploy-project.sh pve-guests-state
./scripts/deploy-project.sh pve-net-hang-watchdog
./scripts/deploy-project.sh pve-backup-scheduler
./scripts/deploy-project.sh autoNAS
./scripts/deploy-project.sh pve-guests-state install --node ebony
Cerinta pentru proiecte:
- proiectele noi trebuie sa ofere fie setup.sh, fie deploy.sh
- setup.sh ramane entrypoint-ul standard pentru install/uninstall pe un singur nod
- orchestratorul comun decide nodurile pe baza cluster-context/madagascar.json si ruleaza proiectul pe toate tintele selectate