Afirmaciones y restricciones

Estoy construyendo una plantilla para construir un archivo de configuración, y el servicio que consume este archivo impone restricciones en las longitudes de los identificadores.

Si un identificador es más largo que, digamos, 6 caracteres, el servicio obtendrá la mitad de la aplicación, fallará y dejará el nodo en un estado inconsistente.

¿Cómo puedo realizar una aserción para desencadenar una falla de transacción de implementación, evitando que el servicio de los nodos de destino esté mal configurado?

Mi circunstancia particular es Salt, pero me gustaría ver cómo otros sistemas resuelven el problema también.

configuration configuration-management linting

— Michael Mol
fuente

Bueno, en el chef agregaré una regla de linting, ya sea rspec o foodcritic, o aseguraré que el identificador coincida en la receta. No tengo idea de la sal, no creo que haya una respuesta genérica, ya que cada administrador de configuración tiene su propia especificidad

— Tensibai

Editaré la respuesta para que sea un poco menos específica.

— Michael Mol

Por el momento, mi contemplación actual para una solución Saltstack + Jinja sería una macro que intente leer desde un archivo que no puede existir. Otros renderizadores funcionarían de manera diferente. Un procesador de Python, por ejemplo, sería trivial; simplemente lanza una excepción.

— Michael Mol

En Ansible: puedes usar asserto failmódulo.

- name: "Make sure web_sites is dictionary"
  fail: msg="web_sites should be dictionary"
  when: web_sites is not dict  


- name: "cluster_name should be shorter than 6 chars"
  assert: 
       that: cluster_name|len <= 6

En Puppet: hay una función de falla evaluada durante la fase de análisis que causa una falla de análisis en el servidor (vea la pregunta en StackOverflow )

 if length($cluster_name) > 6 {
      fail("Cluster name is too long. Should be less than 6 chars.")
 }

— Věroš K.
fuente