Upgrade di Tancredi

Sommario

Tra un rilascio di Tancredi e il successivo (es: 1.0 e 1.1) possono esserci differenze nei file .ini: come impattano sui valori delle installazioni esistenti?

Scenari

1 - Definizione di una nuova variabile

Viene aggiunta una nuova funzionalità ai template di Tancredi che necessitano di nuove variabili con un valore definito in defaults.ini o negli scope di modello.

2 - Modifica del valore di default di una variabile esistente

Nel file defaults.ini o negli scope di modello il valore di default di una variabile necessita di una modifica. In questo momento un caso d'uso esitente è per le variabili caps_*_blacklist.

3 - Rimozione di variabili non più utilizzate

La nuova versione di Tancredi potrebbe non aver più bisogno di alcune variabli. Si possono eliminare dagli scope esistenti, ma se restano danni non ne dovrebbero fare.

Implementazione

a - API PATCH

Richiede uno script di upgrade, come si usa fare con i DB relazionali. Lo script potrebbe richiamare le API, iterando su defaults e tutti i models e facendo PATCH con i nuovi valori in maniera incondizionata ma anche implementando controlli più fini sul valore esitente definendo delle strategie di merge.

Sarebbe adatta per gli scenari 1, 2, 3.

Ricordo che /models/fanvil-X3/version/original fornisce già un punto di accesso tramite le API ai valori di fabbrica di Tancredi - quelli definiti nella ro_dir.

b - INI sed

Variante più a basso livello della precedente. Facile fare 1 e 3. Per 2 facile fare il caso incondizionato. Implementare strategie di merge potrebbe risultare più ostico. Non c'è modo di fare confronti tra il vecchio e il nuovo.

c - cap_ rework

Le variabili cap_ hanno una natura diversa rispetto alle altre variabili: non sono parametri di provisioning e come tali non è necessario che siano sovrascritte dall'interfaccia. Quindi per assicurarci che siano sempre al valore di fabbrica l'interfaccia potrebbe avere cura di non scriverle mai. Inoltre

• potrebbero essere lette dalla UI tramite API version/original (eventualmente da implementare anche su /defaults) ricadendo quindi e ignorate altrove, oppure
• potremmo implementare in Tancredi il merge dello scope tra ro_dir e rw_dir (se già non lo fa?), ossia che il valore di una variabile nello scope è letto prima da ro_dir e poi da rw_dir, l'ultimo che la definisce vince.

Quest'ultima proposta tornerebbe utile anche per il caso 1 - nuova variabile.