OpenTofu 1.13 riduce i valori unknown durante il plan

OpenTofu 1.13 introduce funzioni che riducono i valori unknown in fase di plan. Il planner può così decidere quante istanze creare anche senza conoscere tutti gli attributi, che restano sconosciuti fino all’apply¹.

Con la 1.13 diventano risolvibili espressioni che prima restavano indefinite. In particolare count e le chiavi di for_each. Hint di tipo e di valore aiutano il motore a sbloccare più calcoli già nel plan. Questo limita gli stalli quando il tipo di un input o la sua eventuale nullità non sono determinabili in anticipo¹.

La discussione nasce da un caso reale. Un utente, csar398, voleva mantenere input in YAML ma non riusciva a pianificare quando il valore decodificato governava count. Il nodo critico sta in yamldecode: la funzione può restituire tipi diversi, incluso null. Con un input sconosciuto il planner non può inferire né un tipo stabile né la garanzia che il valore non sia null. Martin Atkins ha descritto così il limite: la combinazione è troppo complessa per essere dedotta in automatico dal motore di OpenTofu¹.

Per gestire formati in ingresso eterogenei serve “fissare” il tipo prima di valutare le espressioni. Qui interviene convert. La funzione forza un valore nel tipo specificato. Applicata all’output di yamldecode, assegna un tipo oggetto noto anche quando l’input YAML resta sconosciuto. Il plan guadagna così un’informazione affidabile sul tipo, senza anticipare gli attributi specifici, che possono restare unknown fino all’apply¹.

Secondo tassello: assumenotnull. La funzione comunica al planner che un valore non è null. Insieme a convert consente di risolvere condizioni sulla nullità e di far convergere count su zero o uno nei casi condizionali. Il contenuto dell’oggetto può restare unknown. Non lo è più il numero di istanze. In pratica si separa la decisione sulle istanze dalla risoluzione dei dettagli, che può attendere l’apply¹.

Il percorso è stato pubblico. Martin Atkins, manutentore di OpenTofu, ha proposto il design in una RFC e ha unito l’implementazione ad agosto¹.

Effetto operativo: gli autori di moduli possono offrire al planner solo ciò che serve davvero, un tipo preciso e una non-nullità garantita. Il motore decide quante risorse creare. Gli attributi, quando ancora ignoti o derivati da input variabili, si definiscono più tardi¹.

Queste funzioni aiutano i moduli che accettano YAML non omogeneo. Un tipo stabilito in anticipo e l’assenza di null dichiarata riducono le incertezze del plan e sbloccano topologie che prima richiedevano workaround, mantenendo la risoluzione dei dettagli al momento giusto: l’apply.