satellite_content_view_version_publish_promote

Una advertencia desde el principio:

Este rol es absurdamente complejo. Lo probé lo mejor que pude, pero no puedo garantizar que no queden errores. Dado que la sincronización del repositorio y las acciones de publicación y/o promoción de la Vista de Contenido cambiarán estos objetos en tu Satellite, te insto a que pruebes antes de usarlo en producción de inmediato. Este rol se proporciona "tal como está" y no me hago responsable de las posibles consecuencias devastadoras que pueda tener. Ten esto en cuenta y prueba con una instantánea disponible para tu Satellite o en un sistema de laboratorio. Muchas gracias :slightly_smiling_face:

Este rol publica y, opcionalmente, promueve tanto versiones de la Vista de Contenido como de la Vista de Contenido Compuesta. Utiliza la colección certificada de Red Hat redhat.satellite.

Ha sido probado en las siguientes versiones de Satellite:

• 6.15
• 6.14
• 6.13

Para usar la colección certificada redhat.satellite necesitas ser suscriptor de Red Hat. Si no tienes suscripciones, puedes hacer uso de la Suscripción para Desarrolladores de Red Hat, que es proporcionada sin costo por Red Hat.

También puedes utilizar la colección upstream theforeman.foreman, pero necesitarías cambiar los nombres de los módulos de redhat.satellite a theforeman.foreman, aunque yo no he probado esto.

El rol fue escrito de tal manera que acepta la definición de variables de las Vistas de Contenido de la misma manera que el rol redhat.satellite.content_view_publish lo hace.

También soporta las Variables Comunes de Roles para la colección redhat.satellite. El repositorio de GitHub de redhat.satellite no contiene una sección sobre qué variables comunes se pueden usar, pero estas se pueden verificar en el código directamente.

Las variables comunes del rol son:

• SATELLITE_SERVER_URL, SATELLITE_SERVER, SATELLITE_URL
• SATELLITE_USERNAME, SATELLITE_USER
• SATELLITE_PASSWORD
• SATELLITE_VALIDATE_CERTS

Reutilizar la misma definición de Vista de Contenido que la colección redhat.satellite te permite mantener la misma definición YAML para tus Vistas de Contenido/Vistas de Contenido Compuesto, aunque recomiendo encarecidamente migrar tu definición YAML a una definición más 'moderna', que tanto Foreman y los roles de Satellite, así como este, acepten.

Para facilitar este proceso, puedes ejecutar este rol con la etiqueta convert (--tags convert), lo que almacenará el YAML convertido en un archivo de tu elección, el cual también deberás especificar con la variable sat_convert_yaml_file.

La conversión se realiza por defecto con un filtro personalizado incluido en este rol (list_of_dicts_to_indented_yaml). Este filtro indenta las listas 'correctamente' con dos espacios, algo que ansible.builtin.to_nice_yaml no hace (la cual es una Limitación conocida que probablemente no sea fácil de resolver, en caso de que te lo preguntaras). El filtro list_of_dicts_to_indented_yaml también añade la posibilidad de poner una clave y un valor específicos en la parte superior de una lista de diccionarios (por defecto name).

Ten en cuenta que este filtro no está destinado a ser utilizado fuera de este rol (por eso también elegí el peor nombre que pude :slightly_smiling_face:). Solo aceptará una lista de diccionarios (ya que eso es lo que generará la conversión) y tendrá un error con cualquier otro tipo de dato. Implementar el análisis de YAML para una variedad de tipos de datos es un desafío por sí mismo. Para este caso particular que tiene el rol, el filtro incluido hace el trabajo bien.

La razón por la que recomiendo encarecidamente migrar de las definiciones de YAML 'legado'[^legacy] es que este rol necesita que la definición esté en un formato específico para que funcione. No te preocupes, lo convierte sobre la marcha, pero esto tiene un costo en el rendimiento ya que necesita iterar a través de todas las definiciones de Vista de Contenido/Vista de Contenido Compuesto y convertir cada una de ellas. Cuanto más grande sea tu definición de Vista de Contenido/Vista de Contenido Compuesto, mayor será el impacto en el rendimiento.

Lo único que este rol no acepta como argumento, pero los demás sí: current_lifecycle_environment. El rol tiene un enfoque diferente, ya que determina el entorno de ciclo de vida actual para cada versión de Vista de Contenido/Vista de Contenido Compuesto de manera dinámica y, por lo tanto, no requiere este argumento.

Dejar current_lifecycle_environment definido en tu definición de Vista de Contenido/Vista de Contenido Compuesto no le molestará a este rol, ya que este atributo nunca se recupera.

El rol añade algunos atributos a la definición de satellite_content_views (que los otros roles no se preocupan por):

• patch_day_exclude: Con esto puedes excluir permanentemente una Vista de Contenido/Vista de Contenido Compuesto de ser procesada. Estas serían Vistas de Contenido/Vistas de Contenido Compuesto que solo tocas en "ocasiones especiales". Por ejemplo, cuando realizas una actualización de Satellite :slightly_smiling_face:. Este atributo es opcional.
• lifecycle_environments: Una lista de entornos de ciclo de vida (también por Vista de Contenido/Vista de Contenido Compuesto) a los que se promoverá la Vista de Contenido/Vista de Contenido Compuesta. Esta lista se puede reducir (ver sección de variables a continuación) cuando sea necesario. Este atributo es opcional para publicar, pero obligatorio para promover.

Diferencias con redhat.satellite.content_view_publish

La forma en que funciona este rol es completamente diferente a la forma en que opera el rol redhat.satellite.content_view_publish.

El rol redhat.satellite.content_view_publish es tan directo como puede ser: publica todas las Vistas de Contenido definidas en satellite_content_views iterando sobre esa lista y las publica. Puede ser de manera asincrónica (async) o una tras de otra. Sin complicaciones. No me malinterpretes, no hay nada de malo en este rol. La forma en que funciona es probablemente exactamente lo que el 98% de los usuarios del rol aprecian.

Soy uno de los 2% que necesita más que eso. Quiero que el rol decida dinámicamente qué Vistas de Contenido/Vistas de Contenido Compuesto publicar, dónde promoverlas e incluso excluir Vistas de Contenido/Vistas de Contenido Compuestas sin redefinir satellite_content_views. Además, no quiero que el rol publique una nueva versión de Vista de Contenido/Vista de Contenido Compuesta si no es necesario, porque nada ha cambiado. Lo mismo para la promoción. Debería promover solo si es necesario y, por lo tanto, solo informar un estado changed si realmente ha cambiado algo. Por supuesto, también quiero limitar los entornos de ciclo de vida a los que se promociona, y no redefiniendo la definición en satellite_content_views.

¿Suena demasiado bueno para ser verdad? Bueno, en parte. He implementado todo lo anterior (y más) en este rol, pero eso tiene sus desventajas: complejidad y velocidad de ejecución.

Hice todo lo posible para reducir la velocidad de ejecución lo más bajo posible, pero es significativamente más lenta que redhat.satellite.content_view_publish, aunque también más versátil.

Para implementar los requisitos descritos anteriormente, técnicamente necesitaría recuperar cada Vista de Contenido/Vista de Contenido Compuesta una por una de la API de Satellite y extraer los datos requeridos. Esto se puede hacer, seguro, mientras se itera sobre todas las Vistas de Contenido/Vistas de Contenido Compuestas y ejecutando redhat.satellite.resource_info para la Vista de Contenido/Vista de Contenido Compuesta que se está iterando actualmente.

O bien, simplemente recuperamos todas las Vistas de Contenido/Vistas de Contenido Compuestas a la vez y filtramos aquellas que no están definidas en satellite_content_views. Recuperar una "gran cantidad" de datos de la API de Satellite es generalmente más rápido en mi experiencia que recuperar pequeños fragmentos uno por uno. Después de todo, lo más probable es que publiques y/o promociones todas las Vistas de Contenido/Vistas de Contenido Compuestas que están presentes en el Satellite y quizás excluyas solo unas pocas. Así que, en última instancia, necesitaríamos recuperar la mayoría de las Vistas de Contenido/Vistas de Contenido Compuestas de todos modos, así que ¿por qué no recuperarlas todas de una vez? :slightly_smiling_face:.

También tengo un montón de verificaciones en su lugar para garantizar que tanto los datos ingresados en el rol como los datos recuperados de la API de Satellite sean tan esperados como sea posible. Sé que esto no es muy 'Ansible', pero quiero asegurarme de que todo esté en la mejor forma posible, lo que evitará resultados inesperados.

Todo lo anterior hace que el rol sea muy versátil, pero muy complejo al mismo tiempo. He comentado secciones complejas en el código lo mejor que pude para asegurarme de que los usuarios de este rol entiendan qué está pasando.

Pero seamos honestos. Este rol no es para principiantes de Ansible. Podrías incluso argumentar que la mayor parte del código en este rol debería ser manejado por un módulo de Ansible dedicado y que lo que estoy haciendo con este rol es pura locura. Podrías tener razón. Pero también creo que este tipo de código no es tan raro como se podría suponer. Después de todo, Ansible es genial para conectar diferentes sistemas y, para eso, a veces necesitas complejidad. Desafortunadamente.

Cuándo considerar usar este rol

Puedes considerar usar este rol en lugar del oficial redhat.satellite.content_view_publish cuando:

1. Quieres promover versiones de Vista de Contenido o versiones de Vista de Contenido Compuestas mientras publicas una nueva versión de Vista de Contenido/Vista de Contenido Compuesta.
2. Quieres promover solo, sin publicar una nueva versión de Vista de Contenido o Vista de Contenido Compuesta, lo cual es idempotente.
3. Quieres promover, pero solo a entornos de ciclo de vida definidos de manera idempotente.
4. Necesitas excluir ciertas Vistas de Contenido o ciertas Vistas de Contenido Compuestas de la publicación o promoción durante los días de parcheo regulares.
5. No quieres preocuparte por el orden en que defines las Vistas de Contenido o Vistas de Contenido Compuestas.
6. Quieres limitar 'dinámicamente' los entornos de ciclo de vida a los que se promueven las versiones de Vista de Contenido, sin redefinir el YAML para las versiones de Vista de Contenido o Vistas de Contenido Compuestas. Esto es útil si haces parches, digamos, cada semana. Pero los lunes solo quieres promover a dev, los martes a qa y los jueves a prod.
7. Quieres publicar y opcionalmente promover una Vista de Contenido en función de si la última versión de la Vista de Contenido es más antigua que la fecha de última sincronización de los repositorios incluidos.
8. Quieres publicar y opcionalmente promover Vistas de Contenido Compuestas solo si los Componentes (versión de Vista de Contenido) se han actualizado desde la última publicación de la Vista de Contenido Compuesta.
9. Quieres asegurarte de que antes de publicar todos los Repositorios estén:
   • Sincronizados
   • Hayan terminado su última sincronización con éxito
   • No estén sincronizándose actualmente
10. Quieres sincronizar Repositorios antes de publicar y opcionalmente promover Vistas de Contenido/Vistas de Contenido Compuestas.
11. Quieres excluir ciertos Repositorios de la verificación y/o sincronización.
12. Quieres esperar a que finalicen los Repositorios actualmente en sincronización (cuando no se inician a través de este rol) antes de publicar y opcionalmente promover Vistas de Contenido/Vistas de Contenido Compuestas.

¿Por qué no contribuiste a la colección certificada de Red Hat/ a la colección de Ansible upstream de Foreman?

Podría preguntar si este tipo de rol es algo que vale la pena contribuir. Teóricamente, podría ser un reemplazo directo para el rol existente content_view_publish, pero es significativamente más complejo y tiene un enfoque diferente en lo que respecta a la validación de datos (los proporcionados por el usuario o de la API). Este rol valida todo para asegurarse de que nada falle durante los días de parcheo, que es algo que me preocupa más que la velocidad de ejecución del rol mismo. También contiene una cantidad considerable de 'locura' relacionada con filtros YAML multiplataforma (aunque en mi opinión está muy bien comentada), que podría ser algo que a otros no les guste.

Escribí este rol principalmente para mí mismo, ya que lo necesito exactamente de esta forma. Podría ser algo para un público más amplio, pero si eso es algo que Red Hat o la comunidad de Foreman quieren mantener a largo plazo (incluso si me inscribo como mantenedor para este rol en particular), es una historia diferente.

Como siempre con el software de código abierto, no puedo garantizar que mantendré este rol durante los próximos tres, cinco, diez o más años, así que se necesita encontrar un nuevo mantenedor cuando sea parte de la colección redhat.satellite y/o theforeman.foreman, en caso de que desaparezca por cualquier razón. Aunque planeo mantener este rol por un buen tiempo, no puedo garantizarlo. Si se considera que es demasiado complejo para que otros lo mantengan, probablemente no se incluirá en ninguna de las colecciones.

Honestamente: No contengas la respiración, ya que definitivamente es demasiado complejo, desafortunadamente :pensive:.

Lo que este rol considera como definición 'legado'

[^legacy]: Los roles redhat.satellite.content_view_publish y también el rol theforeman.foreman.content_view_publish aceptan definiciones de Vista de Contenido/Vista de Contenido Compuesta en los siguientes formatos:

Formato uno, que llamo legacy_a

satellite_content_views:
- 'nombre_vista_contenido1'
- 'nombre_vista_contenido2'
- 'nombre_vista_contenido3'
- etc.

Formato dos, que llamo legacy_b

satellite_content_views:
- content_view: 'nombre_vista_contenido1'
- content_view: 'nombre_vista_contenido2'
- content_view: 'nombre_vista_contenido3'
- etc.

Ambos formatos son, en mi humilde opinión, de calidad inferior.

Típicamente, cuando hay necesidad de identificar un elemento de lista por nombre, se utiliza el atributo name, no algo que describa el tipo de objeto que se define. Especialmente considerando que otro rol de las mismas colecciones (redhat.satellite.content_views o theforeman.foreman.content_views) requiere el atributo name.

No me malinterpretes, no quiero decir que no se defina el atributo name es algo totalmente poco común, pero argumentaría que es una práctica común usar name en lugar de cualquier otra cosa cuando se trata de identificar objetos por nombre.

El formato de 'lista de cadenas' (legacy_a) es incluso más restringido, ya que solo puedes proporcionar una lista de Vistas de Contenido/Vistas de Contenido Compuestas que te gustaría publicar. Nada más, no es posible proporcionar otros atributos. Entiendo por qué esto podría parecer una forma fácil de comenzar con el rol, pero honestamente, ¿no es mucho más complicado/molesto simplemente anteponer un name: frente a cada Vista de Contenido/Vista de Contenido Compuesta? No lo creo :slightly_smiling_face:.

El formato 'correcto' para usar

Esencialmente, especificas tus Vistas de Contenido/Vistas de Contenido Compuestas así:

satellite_content_views:
- name: 'nombre_vista_contenido1'
- name: 'nombre_vista_contenido2'
- name: 'nombre_vista_contenido3'
- etc.

Esto tiene dos beneficios:

• Puedes usar la misma definición de Vistas de Contenido/Vistas de Contenido Compuestas que para el rol (redhat.satellite.content_views)
• Evitas la conversión de este rol, lo que mejora en gran medida el rendimiento

Variables del Rol

variable	por defecto	obligatorio	descripción
satellite_username	sin definir	verdadero	Nombre de usuario para autenticar con la API de Satellite
satellite_password	sin definir	verdadero	Contraseña del usuario para autenticar con la API de Satellite
satellite_server_url	sin definir	verdadero	URL a la API de Satellite (incluyendo http/s://)
satellite_organization	sin definir	verdadero	Nombre de la Organización Satellite para realizar acciones dentro
satellite_content_views	sin definir	verdadero	Vistas de Contenido y Vistas de Contenido Compuestas a publicar y opcionalmente promover
satellite_validate_certs	true	falso	Si validar certificados al conectarse a la API de Satellite
sat_api_timestamp_format	%Y-%m-%d %H:%M:%S %Z	falso	Formato en el cual se representan las marcas de tiempo en la API de Satellite
sat_async_max_time	3600	falso	Tiempo en segundos que cada tarea asincrónica corre hasta que se agota
sat_async_poll_time	0	falso	Tiempo de sondeo de cada tarea asincrónica. Ponlo en 0 para acciones de publicación/promoción concurrentes
sat_async_retries	1200	falso	Frecuencia con la que se deberá comprobar una tarea asincrónica hasta determinar que falló
sat_async_check_delay	3	falso	Retraso entre cada verificación si una tarea asincrónica finalizó
sat_quiet_assert	true	falso	Si suprimir las afirmaciones
sat_check_content_views_known	true	falso	Verificar si todas las Vistas de Contenido/Vistas de Contenido Compuestas definidas a través de satellite_content_views son conocidas por Satellite
sat_check_synchronizing_repositories	false	falso	Si verificar Repositorios actualmente en sincronización [^check_repositories]
sat_check_successful_repository_synchronization	false	falso	Si comprobar si la última sincronización de los Repositorios fue exitosa
sat_check_unsynchronized_repositories	false	falso	Si comprobar Repositorios no sincronizados [^check_repositories]
sat_composite_content_view_version_description	Patch day YYYY-mm-dd	falso	Igual que lo anterior, pero para versiones de Vistas de Contenido Compuesta.
sat_composite_content_views_allowed_lifecycle_environments	sin definir	falso	Limitar los entornos de ciclo de vida a los que puede promoverse. Para CCVs.
sat_content_view_version_description	Patch day YYYY-mm-dd	falso	Descripción de la versión de Vista de Contenido. No la descripción de la CV misma.
sat_content_view_kinds	both	falso	Qué tipos de Vistas de Contenido procesar [^content_view_kinds]
sat_content_views_allowed_lifecycle_environments	sin definir	falso	Limitar los entornos de ciclo de vida a los que puede promoverse. Para Vistas de Contenido.
sat_excluded_composite_content_views	sin definir	falso	Excluir Vistas de Contenido Compuestas de cualquier actividad
sat_excluded_content_views	sin definir	falso	Excluir Vistas de Contenido de cualquier actividad
sat_excluded_repositories	sin definir	falso	Excluir Repositorios de cualquier actividad/comprobaciones
sat_ignore_missing_needs_publish_attribute	false	falso	Ignorar un atributo needs_publish faltante [^needs_publish]
sat_publish_based_on_repository	sin definir	falso	Si publicar Vistas de Contenido basándose en la fecha de sincronización del Repositorio
sat_publish_based_on_component	sin definir	falso	Si publicar Vistas de Contenido Compuestas basándose en sus Componentes incluidos
sat_show_summary	true	falso	Si mostrar un resumen al final del rol, que lista todos los objetos cambiados
sat_skip_legacy_conversion	false	falso	Si omitir la conversión sobre la marcha de definiciones de CV/CCV 'legado'
sat_skip_legacy_assert	false	falso	Desactivar la verificación si un formato legado se puede convertir
sat_skip_assert	false	falso	Si omitir las afirmaciones que verifican todas las variables (assert.yml)
sat_wait_for_repository_synchronization	false	falso	Si esperar a que los Repositorios terminen de sincronizar
sat_synchronize_repositories	false	falso	Si sincronizar Repositorios antes de publicar
sat_convert_yaml_file	sin definir	falso	Archivo en el que se escribirá la definición YAML convertida (si se solicita)
sat_convert_yaml_indent	2	falso	Cuántos espacios debe tener la sangría del YAML convertido
sat_convert_yaml_sort_keys	false	falso	Si ordenar lexicográficamente las claves al exportar el YAML
sat_convert_yaml_explicit_start	true	falso	Si agregar una etiqueta de inicio YAML explícita (---) al archivo convertido
sat_convert_yaml_explicit_end	true	falso	Si agregar una etiqueta de fin YAML explícita (...) al archivo convertido
sat_convert_yaml_use_custom_yaml_filter	true	falso	Si usar el filtro YAML personalizado empaquetado con este rol
sat_convert_yaml_top_key	name	falso	Si poner una clave y un valor específicos en la parte superior de un dict representando una CV/CCV

[^check_repositories]: Todas las verificaciones de Repositorios se realizarán solo en Repositorios que estén incluidos en alguna Vista de Contenido (y Vista de Contenido Compuesta, técnicamente) y que no sean específicamente excluidos a través de sat_excluded_repositories.

[^content_view_kinds]: Esta variable puede tener el valor content_views para procesar solo Vistas de Contenido, composite_content_views para procesar solo Vistas de Contenido Compuestas o both para procesar cualquiera de ellas. De esta manera, puedes limitar las actividades a las Vistas de Contenido o a las Vistas de Contenido Compuestas, si es necesario.

[^needs_publish]: Cuando no se ha realizado ninguna acción durante un período más largo (no conozco el período exacto), el atributo needs_publish está vacío (null) para Vistas de Contenido Compuestas. Por defecto, este rol mostrará un error de que el atributo needs_publish no está definido. Al habilitar la variable sat_ignore_missing_needs_publish_attribute, las Vistas de Contenido Compuestas que no tienen el atributo needs_publish, o lo tienen configurado como null, se agregarán a aquellas Vistas de Contenido Compuestas que necesitan publicarse. Esto efectivamente desactiva la 'Publicación Basada en Componentes' para estas Vistas de Contenido Compuestas. Todas las demás Vistas de Contenido Compuestas con un atributo needs_publishing existente y poblado no se verán afectadas por esto y se evaluarán como de costumbre.

Notas

• sat_publish_based_on_repository solo tiene sentido para Vistas de Contenido. Por lo tanto, se omitirá para Vistas de Contenido Compuestas.
• sat_publish_based_on_component solo es relevante para Vistas de Contenido Compuestas, ya que las Vistas de Contenido Compuestas consisten en uno o más Componentes (=versión de Vista de Contenido).

Dependencias

Este rol utiliza la colección certificada de Red Hat redhat.satellite, que se especifica a través de collections/requirements.yml.

Ejemplo de Playbook

Por favor, ten en cuenta que el ejemplo a continuación también contiene Repositorios y Componentes. Esto no es necesario y no es utilizado por este rol. Incluir estos solo muestra que puedes usar la misma definición de Vista de Contenido/Vista de Contenido Compuesta para este rol que usarías para redhat.satellite.content_views.

Ejemplo complejo

---
- hosts: 'localhost'
  gather_facts: false
  roles:
    - name: 'satellite_content_view_publish_promote'
  vars:
    sat_async_max_time: 3900
    sat_async_poll_time: 0
    sat_async_retries: 2000
    sat_async_check_delay: 2
    sat_content_view_version_description: 'Día de Parche'
    sat_composite_content_view_version_description: 'Día de Parche'
    satellite_server_url: 'https://satellite.example.com'
    satellite_organization: 'org-example'
    sat_only_promote_content_views: false
    sat_only_promote_composite_content_views: false
    sat_publish_based_on_repository: true
    sat_check_unsynchronized_repositories: true
    sat_wait_for_repository_synchronization: true
    sat_check_successful_repository_synchronization: true
    sat_check_synchronizing_repositories: true
    sat_content_view_kinds: 'both'
    sat_synchronize_repositories: false
    sat_check_content_views_known: true
    sat_publish_based_on_component: true
    satellite_content_views:
      - name: 'cv-rhcdn-base-rhel-8'
        lifecycle_environments:
          - 'lce-default-dev'
          - 'lce-default-prod'

        repositories:
          - name: 'Red Hat Enterprise Linux 8 for x86_64 - BaseOS RPMs 8'
            product: 'Red Hat Enterprise Linux for x86_64'

          - name: 'Red Hat Enterprise Linux 8 for x86_64 - AppStream RPMs 8'
            product: 'Red Hat Enterprise Linux for x86_64'

          - name: 'Red Hat Enterprise Linux 8 for x86_64 - BaseOS Kickstart 8.9'
            product: 'Red Hat Enterprise Linux for x86_64'

          - name: 'Red Hat Enterprise Linux 8 for x86_64 - AppStream Kickstart 8.9'
            product: 'Red Hat Enterprise Linux for x86_64'

      - name: 'cv-rhcdn-base-rhel-9'
        lifecycle_environments:
          - 'lce-default-dev'

        repositories:
          - name: 'Red Hat Enterprise Linux 9 for x86_64 - BaseOS RPMs 9'
            product: 'Red Hat Enterprise Linux for x86_64'

          - name: 'Red Hat Enterprise Linux 9 for x86_64 - AppStream RPMs 9'
            product: 'Red Hat Enterprise Linux for x86_64'

          - name: 'Red Hat Enterprise Linux 9 for x86_64 - BaseOS Kickstart 9.3'
            product: 'Red Hat Enterprise Linux for x86_64'

          - name: 'Red Hat Enterprise Linux 9 for x86_64 - AppStream Kickstart 9.3'
            product: 'Red Hat Enterprise Linux for x86_64'

      - name: 'cv-rhcdn-satellite_6_client-rhel-8'
        patch_day_exclude: true
        repositories:
          - name: 'Red Hat Satellite Client 6 for RHEL 8 x86_64 RPMs'
            product: 'Red Hat Enterprise Linux for x86_64'

      - name: 'cv-rhcdn-satellite_6_client-rhel-9'
        patch_day_exclude: true
        repositories:
          - name: 'Red Hat Satellite Client 6 for RHEL 9 x86_64 RPMs'
            product: 'Red Hat Enterprise Linux for x86_64'

      - name: 'ccv-default-rhel-8'                                                                                                                                               
        lifecycle_environments:
          - 'lce-default-dev'
          - 'lce-default-prod'

        components:
          - content_view: 'cv-rhcdn-base-rhel-8'
            latest: true

          - content_view: 'cv-rhcdn-satellite_6_client-rhel-8'
            latest: true

      - name: 'ccv-default-rhel-9'
        lifecycle_environments:
          - 'lce-default-dev'

        components:
          - content_view: 'cv-rhcdn-base-rhel-9'
            latest: true

          - content_view: 'cv-rhcdn-satellite_6_client-rhel-9'
            latest: true

Licencia

GPL-2.0-or-later