Fabric: 'roles' compatibles con v2 o similares

Sinopsis

Al momento de escribir este artículo, la rama v2 tiene una clase Group que debería ser capaz de servir como las unidades antes conocidas como 'roles', también conocido como "un montón de hosts para hacer cosas con / en".

Sin embargo, todavía no existe una forma específica de organizar o etiquetar objetos Group ; está lo suficientemente "hecho" para el caso de uso de API puro de usuarios avanzados que desean desarrollar su propia forma específica de crearlos, pero carece de algo para usuarios orientados a CLI o personas intermedias que desean algo con un marco para construir.

Dicho de otra manera, a menos que esté trabajando exclusivamente con la API, tener objetos de grupo en algún lugar es inútil si la CLI o los bits de llamada de tareas no tienen forma de encontrarlos.

Fondo

En v1, los roles eran efectivamente un único espacio de nombres plano que asignaba etiquetas de cadena simples a lo que serían Grupos en v2, y podían seleccionarse en la CLI en tiempo de ejecución ( fab --roles=web,db ) y / o registrarse como destinos predeterminados para tareas ( @task('db') \n def migrate(): ), al igual que los hosts.

Los usuarios los definieron en env.roledefs , un diccionario simple; cualquier funcionalidad intermedia a avanzada giraba en torno a modificarla, generalmente en tiempo de ejecución (a través de una tarea previa o subrutina), a veces en el momento de carga del módulo.

Casos de uso / necesidades / subfunciones específicas

• Mapeo básico e ingenuo para uso / referencia en cualquier otro lugar del sistema: ingrese un nombre, obtenga algunos iterables de Group sy / o Connection s.
  
  
  
  • El aliasing a menudo quiere ir junto con eso, por ejemplo, un Lexicon lugar de un dict .
  
  
  • Construcciones aún más profundas, como 'empaquetado', por ejemplo, tiene asignaciones directas llamadas db , web , lb , pero luego un nombre de segundo nivel llamado prod que es siempre la unión de los otros tres. Olvidé si agregué eso a Lexicon todavía. Es posible que haya otras subclases de mapas que ya lo hagan.
  
  
  • Además / alternativamente, cosas como globbing u otras sintaxis de cadena, aunque personalmente preferiría aprovechar el hecho de que Python no está "escrito en cadena" ...
  
  
• Útil 'mapeo inverso' para que pueda identificar a qué grupos pertenece una conexión determinada.
  
  
  
  • Problemático: debido a que actualmente no hay un estado compartido global, la respuesta ingenua a esto, usar la identidad, falla porque técnicamente puede crear múltiples objetos Connection idénticos.
  
  
  • Especialmente porque Group puede crearlos implícitamente en su nombre si solo le da cadenas de host abreviadas, aunque esa es solo una opción de conveniencia.
  
  
  • Sin embargo, dada la restricción de ningún estado global, no puedo ver problemas obvios con el uso de pruebas de igualdad en su lugar, por lo que debería ser factible, por ejemplo, if cxn in group funcionaría incluso si cxn es un objeto distinto del miembro igual dentro de group .
  
  
  • Lo único que me viene a la mente es si hubiera vínculos fuertes y con estado de una Conexión a un Grupo (tendrían que ser grupos, en plural) que lo sostuvieran, en lugar de viceversa, pero no puedo ver grandes razones para eso de repente.
  
  
• Muy relacionado con lo anterior: capacidad para inspeccionar / mostrar cuál es el "rol que se está ejecutando actualmente" (algo que la gente quería durante mucho tiempo en la versión 1 que no era trivial debido a su diseño)
  
  
  
  • El problema principal es que se trata en realidad de dos preguntas semi distintas: "¿de qué rol (s) es la parte del host actual, en términos generales" (básicamente, ese caso de uso anterior de la búsqueda inversa) pero también "qué rol (s) era el maquinaria de ejecución específicamente solicitada para correr en contra ".
  
  
  • En otras palabras, dado el host 'foo' que pertenece a los roles A, B y C: dentro de una tarea dada cuyo contexto es 'foo', pero que se ejecutó debido a una solicitud para 'ejecutar en el rol A', es un usuario que busca una respuesta de "A, B y C" (los roles 'foo' está en general) o simplemente "A" (el rol actualmente en ejecución)?
  
  
  • Esto realmente se siente como dos llamadas API distintas, a pesar de que las solicitudes de funciones que recuerdo haber combinado las dos.
  
  
• Selección de destino en la CLI, globalmente y / o por tarea
  
  
  
  • Una extensión del sistema CLI de Invoke para tener en cuenta "indicadores de que todas las tareas superan lo que definen" puede ser útil o necesaria para esto. Lo cual cae firmemente en el territorio de pyinvoke / invoke # 205, de hecho, por lo que acaba de obtener una prioridad más alta de lo que ya era (que era bastante alta).
  
  
• Lo mismo ocurre con los valores predeterminados a nivel de tarea
  
  
  
  • Aunque los valores predeterminados de destino a nivel de tarea realmente quieren ser cualquiera de: conexión, conexiones, obj de grupo, obj de grupo o nombre que evalúa _to_ obj de grupo (podría decirse que eso último es lo único que pertenece directamente a este ticket)
  
  
• Ídem valores predeterminados de nivel de colección (¡NUEVO en v2!)
  
  
  
  • Es decir, "todas las tareas en $ submodule se ejecutan de forma predeterminada en el rol db "
  
  
  • El mismo trato que en el punto anterior: este valor predeterminado quiere permitir una cantidad de valores diferentes, no solo una clave de cadena.
  
  
• ¿Algo más nuevo y emocionante habilitado por un enfoque OO que realmente quiera estar de acuerdo con esto? Recuerde que el énfasis debe estar en los componentes básicos y en la habilitación de usuarios avanzados, no en, por ejemplo, reinventar totalmente sistemas como Chef o Ansible.

Ideas / preocupaciones de implementación

• Si usamos el sistema de configuración como el vector de almacenamiento principal, los valores "quieren" ser primitivos para que puedan almacenarse en yaml, json, etc., pero esa es una lata de gusanos que terminan con "almacenar todos los kwargs de grupo / conexión en un gran ol ' list-o-dicts ", etc.
• Si esperamos que las definiciones estén principalmente en Python, simplemente podemos decir "crear instancias de objetos de grupo", y luego tenemos la opción de fusionar esos datos en el sistema de configuración o dejarlo independiente de alguna manera.
  
  
  
  • Creo que prefiero lo último porque meter literalmente todo en los dictados de configuración anidados parece que conducirá a malas noticias.
  
  
• Las construcciones más profundas como el aliasing y la agrupación agregan complejidad y problemas de orden (es decir, imagine una configuración de alias trivial donde el valor de key1 es un grupo pero el valor de key2 es key1; ahora debe rastrear la estructura dos veces para resolver o verificar key2)
  
  
  
  • aunque si optamos por un enfoque mayormente "hazlo en python", se vuelve muy parecido a la API del sistema de configuración, donde puedes comenzar con una estructura declarativa pero cualquier otra cosa se habilita mediante llamadas a métodos después de esa configuración inicial. ¿No creo que eso sea horrible? EDITAR: y creo que así es exactamente como funciona Lexicon de todos modos.
  
  
• Independientemente del formato, tenemos que averiguar cómo los usuarios avanzados querrán generarlo sobre la marcha a partir de fuentes externas o similares; esto más los problemas con el aliasing y demás, implica que es posible que no queramos esto en una estructura ingenua "almacenada" en algún lugar, sino como una API en algún objeto u objetos que se llama para generarlo.
  
  
  
  • Sospecho que es posible que queramos trabajar 'hacia abajo' a partir de la selección de roles / grupos, llegando a lo que sea el API de nivel más alto para "convertir lo que el usuario proporcionó en una unidad procesable de objetivos", porque los usuarios más avanzados necesariamente querrán tener control total sobre la implementación de esa llamada a la API. Entonces, como siempre, podemos proporcionar lo que se siente como un caso común útil, pero que está claramente marcado como "solo una forma de hacerlo".
  
  
  • @RedKrieg tiene una idea ingeniosa en este sentido en la que tenemos @group como @task , y las funciones no son unidades de trabajo ejecutables, sino que producen objetos de grupo.
  
  
  • Este enfoque reutiliza de forma nativa la jerarquía de tareas (Colección), lo cual es práctico (por qué reinventar la rueda) y elegante (porque en los casos del mundo real, las definiciones de rol / grupo con frecuencia se corresponden muy de cerca con las tareas que las utilizan).
    
    
    
    
    
    • También funciona bien incluso si sus grupos NO se asignan a sus tareas, porque simplemente puede escribir las definiciones en su nivel de colección raíz. Pan comido.
    
    
    
  
  
  • No me queda claro si esto es mejor devolver un solo grupo de cada función, o si queremos la capacidad de producir múltiples grupos (o conexiones), o si es mejor hacerlo no como funciones decoradas en absoluto, sino simplemente como llamadas a API en Colección (como cómo se almacenan las configuraciones a nivel de colección).
  
  
  • Por ejemplo, el caso de uso en el que los datos de grupo / rol son dinámicos y están fuera de Fabric aún deben resolverse aquí (por eso antes señalé que primero debemos identificar la API de nivel más alto para este espacio; luego debemos ver cómo se combina eso con esta idea de nivel intermedio.)