There Is No Draft State

Cambias un valor en la bóveda, redespliegas el servicio para que lo tome, y vuelve igual con el valor viejo.

Eso no es un problema de caché. Un controlador copia los valores de la bóveda al clúster según su propio horario, más o menos cada hora, y el proceso lee su entorno una sola vez, cuando arranca. Redesplegar de inmediato reinicia el proceso contra un secreto que todavía no se actualizó, así que lo más rápido que puedes hacer es también lo que no demuestra nada.

Uno de mis propios scripts le decía a la gente que hiciera exactamente eso. Cambia el valor, corre el pipeline, listo. Estuvo mal todo el tiempo y nadie lo notó, porque cuando el resultado se veía mal la conclusión natural era que el valor estaba mal, y no que nunca había llegado.

También funciona en el otro sentido

Esa parte es molesta. Esta es peor.

Si la sincronización ocurre según un horario, entonces un valor que cambiaste pero que no querías activar todavía igual llega al clúster dentro de la hora. Y después toma efecto en el siguiente arranque del proceso, cuando sea que ocurra. En nuestro clúster de desarrollo las máquinas son interrumpibles, así que los reinicios pasan solos, a horas que nadie eligió.

Así que no existe eso de dejar un secreto listo. No puedes escribir una nueva URL de retorno, un nuevo host o una credencial y dejarla esperando a que aterrice el resto del trabajo. Guardar el valor arranca el reloj, y al reloj no le importa si aquello de lo que depende ya existe.

Escribirlo es desplegarlo, con un reloj que no es tuyo.

La regla que sigo ahora es simple. Cambia un secreto en la misma sesión que las cosas que dependen de él, o no lo cambies todavía.

Encontrar la capa desactualizada

Cuando un valor no se comporta, la pregunta útil es cuál de los cuatro lugares donde vive sigue teniendo el viejo. Revísalos en orden en vez de adivinar.

Qué dice la bóveda, y cuándo se actualizó por última vez. Qué reporta el objeto de sincronización como su última actualización. Qué hay realmente guardado en el clúster. Y por último qué tiene el proceso en ejecución en su entorno, que es lo único que determina el comportamiento.

Cada salto puede ser el desactualizado, y los más cercanos al inicio tranquilizan más de lo que merecen. Un valor correcto en la bóveda te habla de tu intención, no de tu sistema.

Esa es la misma forma de otras cosas que he escrito acá. La alerta que reportó recuperación mientras todo estaba caído. El grep que no devolvió nada porque el comando nunca corrió. En los tres casos la verificación respondió con seguridad a una pregunta, y no era la que se estaba haciendo.

Para aplicar un cambio de inmediato, fuerza la sincronización y después reinicia el proceso, en ese orden. Hacen falta los dos pasos. Hacer el segundo sin el primero es donde empezó todo esto.