Version de publication et de promotion de contenu de satellite

Un mot de précaution :

Ce rôle est extrêmement complexe. J'ai testé autant que possible, mais je ne peux pas garantir qu'il n'y a pas de bugs. Étant donné que la synchronisation des dépôts, la publication et/ou les actions de promotion des vues de contenu changeront ces objets dans votre Satellite, je vous recommande de tester avant de l'utiliser directement en production. Ce rôle est fourni "tel quel" et je ne prends pas la responsabilité des conséquences potentielles qu'il pourrait avoir. Veuillez garder cela à l'esprit et tester avec un instantané en place pour votre Satellite ou sur un système de laboratoire. Merci beaucoup 😊

Ce rôle publie et promeut en option les versions des vues de contenu et des vues de contenu composite. Il utilise la collection certifiée par Red Hat redhat.satellite.

Il a été testé sur les versions de Satellite suivantes :

• 6.15
• 6.14
• 6.13

Pour utiliser la collection certifiée redhat.satellite, vous devez être abonné à Red Hat. Si vous ne disposez d'aucun abonnement, vous pouvez profiter de l'abonnement développeur de Red Hat qui est offert gratuitement par Red Hat.

Vous pouvez également utiliser la collection en amont theforeman.foreman, mais vous devrez changer les noms de module de redhat.satellite à theforeman.foreman - mais je n'ai pas testé cela.

Le rôle a été écrit de manière à accepter la définition de variable des vues de contenu de la même manière que le rôle redhat.satellite.content_view_publish le fait.

Il prend également en charge les Variables de Rôle Communes pour la collection redhat.satellite. Le dépôt GitHub de redhat.satellite ne contient pas de section sur les variables de rôle communes qui peuvent être utilisées, mais celles-ci peuvent être vérifiées directement dans le code.

Les variables de rôle communes sont :

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

Réutiliser la même définition de la vue de contenu que la collection redhat.satellite vous permet de garder la même définition YAML pour vos vues de contenu / vues de contenu composite, bien que je recommande fortement de migrer votre définition YAML vers une définition plus 'moderne', acceptée à la fois par Foreman et les rôles Satellite.

Pour faciliter ce processus, vous pouvez exécuter ce rôle avec le tag convert (--tags convert) qui enregistrera le YAML converti dans un fichier de votre choix, que vous devrez également spécifier avec la variable sat_convert_yaml_file.

La conversion se fait par défaut avec un filtre personnalisé livré avec ce rôle (list_of_dicts_to_indented_yaml). Ce filtre permet d'indentation correcte des listes de deux espaces, ce que ansible.builtin.to_nice_yaml ne fait pas. Le filtre list_of_dicts_to_indented_yaml permet également de mettre une clé et une valeur spécifiques en haut d'une liste de dictionnaires (par défaut name).

Veuillez noter que ce filtre n'est pas destiné à être utilisé en dehors de ce rôle. Il n'acceptera qu'une liste de dictionnaires (car c'est ce que la conversion générera) et échouera sur tout autre type de données. Mettre en œuvre la conversion YAML pour une variété de types de données est une tâche difficile. Pour ce cas d'utilisation particulier, le filtre fourni fait bien son travail.

La raison pour laquelle je recommande fortement de migrer hors des définitions YAML 'héritées' est que ce rôle a besoin que la définition soit faite d'une manière spécifique pour fonctionner. Ne vous inquiétez pas, il convertit au fur et à mesure, mais cela a un coût en termes de performance car il doit itérer à travers toutes les définitions de vues de contenu / vues de contenu composite et convertir chacune d'elles. Plus votre définition de vue de contenu / vue de contenu composite est grande, plus l'impact sur la performance sera important.

La seule chose que ce rôle n'accepte pas comme argument mais que les autres ont : current_lifecycle_environment. Le rôle a une approche différente, car il détermine dynamiquement l'environnement de cycle de vie actuel pour chaque version de vue de contenu / version de vue de contenu composite et ne nécessite donc pas cet argument.

Laisser current_lifecycle_environment défini dans votre définition de vue de contenu / vue de contenu composite ne gênera pas ce rôle, car cet attribut n'est jamais récupéré.

Le rôle ajoute certains attributs à la définition de satellite_content_views (que les autres rôles ne prendront pas en compte) :

• patch_day_exclude : Avec cela, vous pouvez exclure définitivement une vue de contenu / vue de contenu composite du traitement. Ce seraient des vues de contenu / vues de contenu composite que vous ne touchez qu'à des "occasions spéciales".
• lifecycle_environments : Une liste d'environnements de cycle de vie (également par vue de contenu / vue de contenu composite) vers lesquels promouvoir la vue de contenu / vue de contenu composite. Cette liste peut être réduite à la demande. Cet attribut est optionnel pour la publication, mais obligatoire pour la promotion.

Différences avec redhat.satellite.content_view_publish

Le fonctionnement de ce rôle est complètement différent de celui du rôle redhat.satellite.content_view_publish.

Le rôle redhat.satellite.content_view_publish est aussi simple que possible : Publiez toutes les vues de contenu définies dans satellite_content_views en les parcourant et en les publiant. Soit de manière asynchrone (async), soit l'une après l'autre. Pas de cloche ni de sifflet. Ne vous méprenez pas, il n'y a absolument rien de mal avec ce rôle. Sa façon de fonctionner est probablement exactement ce que 98% des utilisateurs du rôle apprécient.

Je fais partie des 2% qui ont besoin de plus. Je veux que le rôle décide dynamiquement quelles vues de contenu / vues de contenu composite publier, où les promouvoir et même exclure des vues de contenu / vues de contenu composite sans redéfinir satellite_content_views. De plus, je ne veux pas que le rôle publie une nouvelle version de vue de contenu / vue de contenu composite si cela n'est pas nécessaire, car rien n'a changé. La même chose pour la promotion. Il ne devrait promouvoir que si c'est nécessaire et donc ne signaler un statut changed que si quelque chose a vraiment changé. Bien sûr, je veux aussi limiter les environnements de cycle de vie auxquels il promeut - et pas en redéfinissant la définition dans satellite_content_views.

Cela semble trop beau pour être vrai ? Eh bien, en quelque sorte. J'ai implémenté tout ce qui précède (et plus) dans ce rôle, mais cela présente des inconvénients : Complexité et vitesse d'exécution.

J'ai fait de mon mieux pour réduire la vitesse d'exécution au minimum, mais elle est significativement plus lente que redhat.satellite.content_view_publish - mais aussi plus polyvalente.

Pour mettre en œuvre les exigences décrites ci-dessus, je devrais techniquement récupérer chaque vue de contenu / vue de contenu composite une par une depuis l'API Satellite et extraire les données nécessaires. Cela peut sûrement être fait en parcourant toutes les vues de contenu / vues de contenu composite et en exécutant redhat.satellite.resource_info pour la vue de contenu / vue de contenu composite actuellement en cours d'itération.

Ou bien, nous récupérons tout d'un coup et filtrons ceux qui ne sont pas définis dans satellite_content_views. Récupérer une "grosse masse" de données depuis l'API Satellite est généralement plus rapide d'après mon expérience que de récupérer de petits morceaux un par un. Après tout, vous publieriez et/ou promouveriez très probablement toutes les vues de contenu / vues de contenu composite présentes dans le Satellite et vous pourriez exclure seulement quelques-unes. Donc au final, nous devrions récupérer la majorité des vues de contenu / vues de contenu composite de toute façon, alors pourquoi ne pas toutes les récupérer en une fois 😊.

J'ai également beaucoup de vérifications en place pour garantir que tant les données fournies au rôle que les données récupérées de l'API Satellite sont aussi attendues. Je sais, ce n'est pas très Ansible, mais je veux m'assurer que tout est aussi conforme que possible, ce qui empêchera des résultats inattendus.

Tout cela rend le rôle très polyvalent, mais très complexe en même temps. J'ai commenté les sections complexes dans le code autant que possible pour garantir que les utilisateurs de ce rôle comprennent ce qui se passe.

Mais soyons honnêtes. Ce rôle n'est pas fait pour les débutants en Ansible. Vous pourriez même soutenir que la plupart du code dans ce rôle devrait être géré par un module Ansible dédié et ce que je fais avec ce rôle est juste de la pure folie. Vous pourriez avoir raison. Mais je pense aussi que ce genre de code n'est pas aussi rare qu'on pourrait le supposer. Après tout, Ansible est excellent pour connecter différents systèmes et pour cela, vous avez parfois besoin de complexité. Malheureusement.

Quand envisager d'utiliser ce rôle

Vous pouvez envisager d'utiliser ce rôle plutôt que l'official redhat.satellite.content_view_publish lorsque :

1. Vous souhaitez promouvoir des versions de vue de contenu ou des versions de vue de contenu composite tout en publiant une nouvelle version de vue de contenu / vue de contenu composite.
2. Vous souhaitez promouvoir seulement, sans publier une nouvelle version de vue de contenu ou de vue de contenu composite, de manière idempotente.
3. Vous souhaitez promouvoir, mais uniquement vers des environnements de cycle de vie définis de manière idempotente.
4. Vous devez exclure certaines vues de contenu ou certaines vues de contenu composite de la publication ou de la promotion lors de journées de patch régulières.
5. Vous ne souhaitez pas vous soucier de l'ordre dans lequel vous définissez les vues de contenu ou les vues de contenu composite.
6. Vous souhaitez limiter 'dynamiquement' les environnements de cycle de vie auxquels les versions de vues de contenu sont promues, sans redéfinir le YAML pour les versions de vue de contenu ou de vue de contenu composite. C'est utile si vous appliquez des correctifs, par exemple, chaque semaine. Mais le lundi, vous souhaitez seulement promouvoir vers dev, le mardi vers qa et le jeudi vers prod.
7. Vous souhaitez publier et éventuellement promouvoir une vue de contenu en fonction de si la dernière version de la vue de contenu est plus ancienne que la dernière date de synchronisation des dépôts inclus.
8. Vous souhaitez publier et éventuellement promouvoir des vues de contenu composite uniquement si les composants (version de vue de contenu) ont été mis à jour depuis la dernière publication de la vue de contenu composite.
9. Vous souhaitez vous assurer qu'avant la publication, tous les dépôts sont :
   • Synchronisés
   • Ont terminé leur dernière synchronisation avec succès
   • Ne sont pas actuellement en cours de synchronisation.
10. Vous souhaitez synchroniser les dépôts avant de publier et éventuellement promouvoir des vues de contenu / vues de contenu composite.
11. Vous souhaitez exclure certains dépôts de la vérification et/ou de la synchronisation.
12. Vous souhaitez attendre que les dépôts en cours de synchronisation (lorsqu'ils ne sont pas déclenchés via ce rôle) terminent avant de publier et éventuellement promouvoir des vues de contenu / vues de contenu composite.

Pourquoi n'avez-vous pas contribué à la collection certifiée par Red Hat / à la collection Foreman Ansible en amont ?

Je pourrais me demander si un tel rôle vaut la peine d'être contribué. Cela pourrait théoriquement être un remplacement direct pour le rôle existant content_view_publish, mais il est considérablement plus complexe et a une approche différente en matière de validation des données (fournies par l'utilisateur ou API). Ce rôle valide tout pour s'assurer que rien ne se brise pendant les journées de patch, ce qui est quelque chose que je crains plus que la vitesse d'exécution du rôle lui-même. Il contient également pas mal de 'folie' complexe concernant le filtre YAML multi-lignes (bien que, à mon avis, très bien commentée), ce qui pourrait être quelque chose que d'autres n'aimeront pas.

J'ai écrit ce rôle principalement pour moi-même, car j'en ai exactement besoin comme ça. Cela pourrait être quelque chose pour le public plus large, mais savoir si c'est quelque chose que Red Hat ou la communauté Foreman souhaite entretenir à long terme (même si je m'inscris comme mainteneur pour ce rôle particulier), c'est une autre histoire.

Comme toujours avec Open Source, je ne peux pas garantir que je maintiendrai ce rôle pendant les trois, cinq, dix prochaines années, donc un nouveau mainteneur doit être trouvé lorsqu'il fait partie de la collection redhat.satellite et/ou theforeman.foreman, si jamais je devais disparaître pour une raison ou une autre. Bien que j'aie absolument l'intention de maintenir ce rôle pendant un certain temps, je peux certainement pas le garantir. S'il est jugé trop complexe à maintenir pour d'autres, il ne fera probablement pas partie de l'une ou l'autre des collections.

Honnêtement : ne vous attendez pas à cela, car c'est de toute évidence trop complexe, malheureusement 😞.

Ce que ce rôle considère comme une définition 'héritée'

Les rôles redhat.satellite.content_view_publish et également le rôle theforeman.foreman.content_view_publish acceptent les définitions de vues de contenu / vues de contenu composite dans les formats suivants :

Format un, que j'appelle héritage_a

satellite_content_views:
- 'content_view_name1'
- 'content_view_name2'
- 'content_view_name3'
- etc.

Format deux, que j'appelle héritage_b

satellite_content_views:
- content_view: 'content_view_name1'
- content_view: 'content_view_name2'
- content_view: 'content_view_name3'
- etc.

À mon humble avis, les deux formats sont en dessous de ce que je considère comme acceptable.

Typiquement, lorsque vous devez identifier un élément de liste par son nom, l'attribut name est utilisé - pas quelque chose qui décrit le type d'objet qui est défini. Surtout, en tenant compte qu'un autre rôle de la même collection (redhat.satellite.content_views ou theforeman.foreman.content_views) exige l'attribut name.

Ne vous méprenez pas, je ne dis pas qu'il est absolument rare de ne pas avoir l'attribut name défini, mais je soutiendrais que c'est une pratique assez courante d'utiliser name plutôt que n'importe quel autre attribut lorsqu'il s'agit d'identifier des objets par leur nom.

Le format 'liste de chaînes' (héritage_a) est encore plus contraignant, car vous ne pouvez fournir qu'une liste de vues de contenu / vues de contenu composite que vous souhaitez publier. Rien de plus, aucun autre attribut n'est - bien sûr - possible. Je comprends pourquoi cela pourrait sembler une manière facile de commencer avec le rôle, mais honnêtement, n'est-il pas beaucoup plus compliqué/ennuyeux de simplement ajouter un name: devant chaque vue de contenu / vue de contenu composite ? Je ne pense pas 😊.

Le format 'correct' à utiliser

Fondamentalement, vous spécifiez vos vues de contenu / vues de contenu composite comme ceci :

satellite_content_views:
- name: 'content_view_name1'
- name: 'content_view_name2'
- name: 'content_view_name3'
- etc.

Cela a deux avantages :

• Vous pouvez utiliser la même définition de vues de contenu / vues de contenu composite que pour le rôle (redhat.satellite.content_views)
• Vous évitez la conversion de ce rôle, ce qui améliore considérablement la performance

Variables de rôle

Variable	Par défaut	Obligatoire	Description
satellite_username	Non défini	Oui	Nom d'utilisateur pour l'authentification auprès de l'API Satellite
satellite_password	Non défini	Oui	Mot de passe de l'utilisateur pour l'authentification auprès de l'API Satellite
satellite_server_url	Non défini	Oui	URL de l'API Satellite (incluant http/s://)
satellite_organization	Non défini	Oui	Nom de l'organisation Satellite pour effectuer des actions
satellite_content_views	Non défini	Oui	Vues de contenu et Vues de contenu composite à publier et éventuellement promouvoir
satellite_validate_certs	true	Non	Indique si les certificats doivent être validés lors de la connexion à l'API
sat_api_timestamp_format	%Y-%m-%d %H:%M:%S %Z	Non	Format dans lequel les horodatages sont représentés dans l'API Satellite
sat_async_max_time	3600	Non	Temps en secondes durant lequel chaque tâche asynchrone tourne avant d'expirer
sat_async_poll_time	0	Non	Temps de sondage de chaque tâche asynchrone. Défini à 0 pour des actions de publication/promotion simultanées
sat_async_retries	1200	Non	Fréquence à laquelle une tâche asynchrone doit être vérifiée jusqu'à ce qu'elle soit déterminée comme échouée
sat_async_check_delay	3	Non	Délai entre chaque vérification pour savoir si une tâche asynchrone est terminée
sat_quiet_assert	true	Non	Indique s'il faut réduire les déclarations d'assertion
sat_check_content_views_known	true	Non	Vérifie si toutes les CVs/CCVs définies via satellite_content_views sont connues à Satellite
sat_check_synchronizing_repositories	false	Non	Indique s'il faut vérifier les dépôts actuellement en cours de synchronisation
sat_check_successful_repository_synchronization	false	Non	Indique s'il faut vérifier si la dernière synchronisation des dépôts a été réussie
sat_check_unsynchronized_repositories	false	Non	Indique s'il faut vérifier les dépôts non synchronisés
sat_composite_content_view_version_description	Patch jour YYYY-mm-dd	Non	Identique à ci-dessus, mais pour les versions de vues de contenu composite
sat_composite_content_views_allowed_lifecycle_environments	Non défini	Non	Limite les environnements de cycle de vie auxquels une promotion peut avoir lieu.
sat_content_view_version_description	Patch jour YYYY-mm-dd	Non	Description de la version de la vue de contenu. Pas la description de la vue de contenu elle-même.
sat_content_view_kinds	both	Non	Quel type de vues de contenu à traiter [^content_view_kinds]
sat_content_views_allowed_lifecycle_environments	Non défini	Non	Limite les environnements de cycle de vie auxquels une promotion peut avoir lieu.
sat_excluded_composite_content_views	Non défini	Non	Exclut les vues de contenu composite de toute activité
sat_excluded_content_views	Non défini	Non	Exclut les vues de contenu de toute activité
sat_excluded_repositories	Non défini	Non	Exclut les dépôts de toute activité/vérification
sat_ignore_missing_needs_publish_attribute	false	Non	Ignore un attribut needs_publish manquant [^needs_publish]
sat_publish_based_on_repository	Non défini	Non	Indique si les vues de contenu doivent être publiées en fonction de la date de synchronisation du dépôt
sat_publish_based_on_component	Non défini	Non	Indique si les vues de contenu composites doivent être publiées en fonction de leurs composants inclus
sat_show_summary	true	Non	Indique s'il faut afficher un résumé à la fin du rôle, listant tous les objets modifiés
sat_skip_legacy_conversion	false	Non	Indique s'il faut sauter la conversion en vol des définitions CV/CCV 'héritées'
sat_skip_legacy_assert	false	Non	Désactive la vérification si un format hérité peut être converti
sat_skip_assert	false	Non	Indique s'il faut sauter les déclarations d'assertion qui vérifient toutes les variables (assert.yml)
sat_wait_for_repository_synchronization	false	Non	Indique s'il faut attendre que les dépôts aient terminé de se synchroniser
sat_synchronize_repositories	false	Non	Indique s'il faut synchroniser les dépôts avant de publier
sat_convert_yaml_file	Non défini	Non	Fichier dans lequel la définition YAML convertie sera écrite (si demandé)
sat_convert_yaml_indent	2	Non	Quel est le niveau d'indentation (nombre d'espaces) du YAML converti
sat_convert_yaml_sort_keys	false	Non	Indique s'il faut trier les clés aléatoirement lors de l'exportation du YAML
sat_convert_yaml_explicit_start	true	Non	Indique s'il faut ajouter une balise de début YAML explicite (---) au fichier converti
sat_convert_yaml_explicit_end	true	Non	Indique s'il faut ajouter une balise de fin YAML explicite (...) au fichier converti
sat_convert_yaml_use_custom_yaml_filter	true	Non	Indique s'il faut utiliser le filtre YAML personnalisé emballé avec ce rôle
sat_convert_yaml_top_key	name	Non	Indique s'il faut mettre une clé et une valeur spécifiques en haut d'un dictionnaire représentant une CV/CCV

[^check_repositories]: Toutes les vérifications de dépôts ne seront effectuées que sur les dépôts qui sont inclus dans une vue de contenu (et vue de contenu composite, techniquement) et ne sont pas spécifiquement exclus via sat_excluded_repositories.

[^content_view_kinds]: Cette variable peut prendre la valeur content_views pour traiter uniquement les vues de contenu, composite_content_views pour traiter uniquement les vues de contenu composite ou both pour traiter les deux. Cela permet de limiter les activités aux vues de contenu ou aux vues de contenu composite, si nécessaire.

[^needs_publish]: Lorsqu'aucune action n'a été effectuée pendant une certaine période (je ne connais pas le délai exact), l'attribut needs_publish est vide (null) pour les vues de contenu composites. Par défaut, ce rôle affichera une erreur indiquant que l'attribut needs_publish n'est pas défini. En activant la variable sat_ignore_missing_needs_publish_attribute, les vues de contenu composites qui n'ont pas l'attribut needs_publish, ou qui l'ont défini sur null, seront ajoutées à celles qui doivent être publiées. Cela désactive effectivement la "publication basée sur les composants" pour ces vues de contenu composites. Toutes les autres vues de contenu composites avec un attribut needs_publish existant et peuplé ne sont pas affectées par cela et seront évaluées comme d'habitude.

Notes

• sat_publish_based_on_repository n'a un sens que pour les vues de contenu. Par conséquent, il sera ignoré pour les vues de contenu composites.
• sat_publish_based_on_component n'est pertinent que pour les vues de contenu composites, car les vues de contenu composites consistent en un ou plusieurs composants (=version de vue de contenu).

Dépendances

Ce rôle utilise la collection certifiée par Red Hat redhat.satellite, qui est spécifiée via collections/requirements.yml.

Exemple de Playbook

Veuillez noter que l'exemple ci-dessous contient également des dépôts et des composants. Ce n'est pas requis et n'est pas utilisé par ce rôle. L'inclusion de ceux-ci montre juste que vous pouvez utiliser la même définition de vue de contenu / vue de contenu composite pour ce rôle que vous utiliserez pour redhat.satellite.content_views.

Exemple complexe

---
- hôtes : 'localhost'
  collecter_faits : faux
  rôles :
    - nom : '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: 'Jour de patch'
    sat_composite_content_view_version_description: 'Jour de patch'
    satellite_server_url: 'https://satellite.example.com'
    satellite_organization: 'org-example'
    sat_only_promote_content_views: faux
    sat_only_promote_composite_content_views: faux
    sat_publish_based_on_repository: vrai
    sat_check_unsynchronized_repositories: vrai
    sat_wait_for_repository_synchronization: vrai
    sat_check_successful_repository_synchronization: vrai
    sat_check_synchronizing_repositories: vrai
    sat_content_view_kinds: 'both'
    sat_synchronize_repositories: faux
    sat_check_content_views_known: vrai
    sat_publish_based_on_component: vrai
    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: vrai
        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: vrai
        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: vrai

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

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

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

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

Licence

GPL-2.0-or-later