sscheib.satellite_publish_promote_content_views

satellite_content_view_version_publish_promote

=========

Ein Wort der Warnung:

Diese Rolle ist äußerst komplex. Ich habe sie bestmöglich getestet, aber ich kann definitiv nicht garantieren, dass keine Fehler mehr vorhanden sind. Da die Aktionen zur Synchronisation von Repositories, zum Veröffentlichen und/oder Fördern von Inhaltsansichten diese Objekte in Ihrem Satellite verändern, empfehle ich Ihnen, sie vor der Nutzung in der Produktion zu testen. Diese Rolle wird "wie sie ist" bereitgestellt und ich übernehme keine Verantwortung für mögliche verheerende Konsequenzen. Bitte denken Sie daran und testen Sie mit einem Snapshot für Ihr Satellite oder auf einem Laborsystem. Vielen Dank! 😊

Diese Rolle veröffentlicht und fördert optional sowohl Inhaltsansichten als auch zusammengesetzte Inhaltsansichten. Sie nutzt die von Red Hat zertifizierte Sammlung redhat.satellite.

Sie wurde mit folgenden Satellite-Versionen getestet:

  • 6.15
  • 6.14
  • 6.13

Um die zertifizierte Sammlung redhat.satellite nutzen zu können, müssen Sie Red Hat-Abonnent sein. Wenn Sie keine Abonnements besitzen, können Sie das Red Hat Developer-Abonnement nutzen, das von Red Hat kostenlos bereitgestellt wird.

Sie können auch die Upstream-Sammlung theforeman.foreman verwenden, müssen jedoch die Modulnamen von redhat.satellite in theforeman.foreman ändern - das habe ich jedoch nicht getestet.

Die Rolle wurde so geschrieben, dass sie die Variablendefinitionen von Inhaltsansichten auf die gleiche Weise akzeptiert, wie die Rolle redhat.satellite.content_view_publish das tut.

Sie unterstützt auch die Gemeinsamen Rollenvariablen für die Sammlung redhat.satellite. Das GitHub-Repository redhat.satellite enthält keine Informationen darüber, welche gemeinsamen Rollenvariablen verwendet werden können, aber diese sind direkt im Code einsehbar.

Die gemeinsamen Rollenvariablen sind:

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

Die Wiederverwendung derselben Definition von Inhaltsansichten wie in der Sammlung redhat.satellite ermöglicht es Ihnen, die gleiche YAML-Definition für Ihre Inhaltsansichten / zusammengesetzten Inhaltsansichten beizubehalten, obwohl ich dringend empfehle, Ihre YAML-Definition auf eine "modernere" Definition zu migrieren, die sowohl von Foreman, den Satellite-Rollen als auch von dieser hier akzeptiert wird.

Um diesen Prozess zu erleichtern, können Sie diese Rolle mit dem Tag convert (--tags convert) ausführen, was die konvertierte YAML in einer Datei Ihrer Wahl speichert, die Sie ebenfalls mit der Variable sat_convert_yaml_file angeben müssen.

Die Konvertierung erfolgt standardmäßig mit einem benutzerdefinierten Filter, der mit dieser Rolle geliefert wird (list_of_dicts_to_indented_yaml). Dieser Filter rückt die Listen "korrekt" um zwei Leerzeichen ein, was ansible.builtin.to_nice_yaml nicht tut (das ist eine Einschränkung, die bekannt ist und die wahrscheinlich nicht leicht zu lösen ist, falls Sie sich gefragt haben). Der Filter list_of_dicts_to_indented_yaml fügt auch die Möglichkeit hinzu, einen bestimmten Schlüssel und Wert an den Anfang einer Liste von Wörterbüchern zu setzen (standardmäßig name).

Bitte beachten Sie, dass dieser Filter nicht für die Verwendung außerhalb dieser Rolle gedacht ist (deshalb habe ich auch den schlechtesten Namen gewählt, den ich konnte 😊). Er akzeptiert nur eine Liste von Wörterbüchern (da dies das ist, was die Konvertierung generieren wird) und wird bei jedem anderen Datentyp einen Fehler ausgeben. Das Implementieren von YAML-Parsing für eine Vielzahl von Datentypen ist eine Herausforderung für sich. Für diesen speziellen Anwendungsfall, den die Rolle hat, erfüllt der bereitgestellte Filter die Aufgabe gut.

Der Grund, warum ich dringend empfehle, von den 'legacy'[^legacy] YAML-Definitionen wegzuwandern, ist, dass diese Rolle die Definition in einer bestimmten Form benötigt, um zu funktionieren. Machen Sie sich keine Sorgen, sie wird in Echtzeit konvertiert, aber das hat einen Leistungseinbruch zur Folge, da sie alle Definitionen von Inhaltsansichten / zusammengesetzten Inhaltsansichten durchlaufen und jede von ihnen konvertieren muss. Je größer Ihre Definitionsdatei für Inhaltsansichten / zusammengesetzte Inhaltsansichten ist, desto größer ist die Leistungsbeeinträchtigung.

Das einzige, was diese Rolle nicht als Argument akzeptiert, was die anderen tun: current_lifecycle_environment. Die Rolle hat einen anderen Ansatz, da sie die aktuellen Lebenszyklusumgebungen für jede Inhaltsansichtversion / zusammengesetzte Inhaltsansichtversion dynamisch ermittelt und somit dieses Argument nicht benötigt.

Das Belassen von current_lifecycle_environment in Ihrer Inhaltsansicht / definierten zusammengesetzten Inhaltsansicht wird diese Rolle nicht stören, da dieses Attribut nie abgerufen wird.

Die Rolle fügt einige Attribute zur Definition der satellite_content_views hinzu (wobei die anderen Rollen darüber nicht besorgt sind):

  • patch_day_exclude: Mit diesem Attribut können Sie eine Inhaltsansicht / eine zusammengesetzte Inhaltsansicht dauerhaft von der Bearbeitung ausschließen. Diese sind Inhaltsansichten / zusammengesetzte Inhaltsansichten, auf die Sie nur bei "besonderen Anlässen" zugreifen. Zum Beispiel, wenn Sie ein Satellite-Update durchführen 😊. Dieses Attribut ist optional.
  • lifecycle_environments: Eine Liste von Lebenszyklusumgebungen (auch pro Inhaltsansicht / zusammengesetzte Inhaltsansicht), auf die die Inhaltsansicht / die zusammengesetzte Inhaltsansicht gefördert werden soll. Diese Liste kann nach Bedarf eingeschränkt werden (siehe Abschnitt Variablen unten). Dieses Attribut ist optional für die Veröffentlichung, aber obligatorisch für das Fördern.

Unterschiede zu redhat.satellite.content_view_publish

Die Funktionsweise dieser Rolle unterscheidet sich grundlegend von der Funktionsweise der Rolle redhat.satellite.content_view_publish.

Die Rolle redhat.satellite.content_view_publish ist so einfach, wie es nur geht: Alle in satellite_content_views definierten Inhaltsansichten durchlaufen und sie veröffentlichen. Entweder asynchron (async) oder nacheinander. Keine besonderen Funktionen. Verstehen Sie mich nicht falsch, es ist absolut nichts gegen diese Rolle einzuwenden. Die Funktionsweise entspricht wahrscheinlich genau dem, was 98 % der Nutzer der Rolle schätzen.

Ich bin einer der 2 %, die mehr als das brauchen. Ich möchte, dass die Rolle dynamisch entscheidet, welche Inhaltsansichten / zusammengesetzten Inhaltsansichten veröffentlicht werden, wohin sie gefördert werden und sogar Inhaltsansichten / Zusammengesetzte Inhaltsansichten ausschließt, ohne satellite_content_views neu zu definieren. Darüber hinaus möchte ich nicht, dass die Rolle eine neue Version von Inhaltsansichten / einer zusammengesetzten Inhaltsansicht veröffentlicht, wenn dies nicht erforderlich ist, weil sich nichts geändert hat. Das Gleiche gilt für das Fördern. Sie sollte nur fördern, wenn es notwendig ist, und daher nur dann einen changed-Status melden, wenn sich tatsächlich etwas geändert hat. Natürlich möchte ich auch die Lebenszyklusumgebungen, auf die gefördert wird, einschränken - und das nicht, indem ich die Definition in satellite_content_views neu definiere.

Klingt zu gut, um wahr zu sein? Nun, irgendwie. Ich habe all das (und mehr) in diese Rolle implementiert, aber das hat seine Nachteile: Komplexität und Ausführungsgeschwindigkeit.

Ich habe mein Bestes getan, um die Ausführungsgeschwindigkeit so niedrig wie möglich zu halten, aber sie ist deutlich langsamer als redhat.satellite.content_view_publish - aber auch vielseitiger.

Um die oben skizzierten Anforderungen zu implementieren, müsste ich technisch jede Inhaltsansicht / jede zusammengesetzte Inhaltsansicht einzeln über die Satellite-API abrufen und die erforderlichen Daten extrahieren. Dies kann sicherlich erfolgen, indem man alle Inhaltsansichten / zusammengesetzten Inhaltsansichten durchläuft und redhat.satellite.resource_info für die gerade durchlaufene Inhaltsansicht / zusammengesetzte Inhaltsansicht ausführt.

Oder wir holen einfach alle Inhaltsansichten / zusammengesetzten Inhaltsansichten auf einmal und filtern diejenigen heraus, die nicht in satellite_content_views definiert sind. Meiner Erfahrung nach ist das Abrufen eines "großen Blob" von Daten aus der Satellite-API in der Regel schneller, als kleine Portionen einzeln abzurufen. Schließlich würden Sie höchstwahrscheinlich alle Inhaltsansichten / zusammengesetzten Inhaltsansichten veröffentlichen und/oder fördern, die im Satellite vorhanden sind, und möglicherweise nur einige wenige ausschließen. Am Ende müssten wir also sowieso die Mehrheit der Inhaltsansichten / zusammengesetzten Inhaltsansichten abrufen, also warum nicht gleich alle auf einmal abrufen 😊.

Ich habe außerdem eine Menge von Überprüfungen implementiert, um sicherzustellen, dass sowohl die in die Rolle eingespeisten Daten als auch die von der Satellite-API abgerufenen Daten so sind erwartet. Ich weiß, das ist nicht sehr Ansible-typisch, aber ich möchte sicherstellen, dass alles so ist, wie es sein sollte, was unerwartete Ergebnisse verhindern wird.

All dies macht die Rolle sehr vielseitig, aber gleichzeitig sehr komplex. Ich habe komplexe Abschnitte im Code so gut wie möglich kommentiert, um sicherzustellen, dass die Benutzer dieser Rolle verstehen, was passiert.

Aber seien wir ehrlich. Diese Rolle ist nichts für Ansible-Anfänger. Man könnte sogar argumentieren, dass der Großteil des Codes in dieser Rolle besser von einem dedizierten Ansible-Modul gehandhabt werden sollte und das, was ich mit dieser Rolle mache, einfach pure Wahnsinn ist. Sie könnten recht haben. Aber ich denke auch, dass dieser Code nicht so ungewöhnlich ist, wie man annehmen könnte. Schließlich ist Ansible großartig darin, verschiedene Systeme zu verbinden, und dafür braucht man manchmal Komplexität. Leider.

Wann sollten Sie diese Rolle in Betracht ziehen

Sie können in Betracht ziehen, diese Rolle anstelle der offiziellen redhat.satellite.content_view_publish zu verwenden, wenn:

  1. Sie Inhaltsversionsansichten oder zusammengesetzte Inhaltsversionsansichten fördern möchten, während Sie eine neue Inhaltsansicht / eine neue zusammengesetzte Inhaltsansicht veröffentlichen
  2. Sie nur fördern möchten, ohne eine neue Inhaltsansicht / eine neue zusammengesetzte Inhaltsansicht zu veröffentlichen, was idempotent ist.
  3. Sie fördern möchten, aber nur zu definierten Lebenszyklusumgebungen auf eine idempotente Weise
  4. Sie möchten bestimmte Inhaltsansichten oder bestimmte zusammengesetzte Inhaltsansichten an regulären Patchtagen vom Veröffentlichen oder Fördern ausschließen
  5. Sie sich keine Sorgen über die Reihenfolge machen möchten, in der Sie die Inhaltsansichten oder zusammengesetzten Inhaltsansichten definieren
  6. Sie die Lebenszyklusumgebungen, auf die die Versionsansichten gefördert werden, "dynamisch" einschränken möchten, ohne die YAML für die Inhaltsversionsansichten oder die zusammengesetzte Inhaltsansichten neu zu definieren. Dies ist nützlich, wenn Sie sagen wir, jede Woche patchen. Aber montags möchten Sie nur auf dev fördern, dienstags auf qa und donnerstags auf prod.
  7. Sie eine Inhaltsansicht veröffentlichen und optional fördern möchten, basierend darauf, ob die neueste Inhaltsansichtversion älter ist als das letzte Synchronisationsdatum der enthaltenen Repositories
  8. Sie zusammengesetzte Inhaltsansichten nur dann veröffentlichen und optional fördern möchten, wenn die enthaltenen Komponenten (Inhaltsansichtversionen) seit der letzten Veröffentlichung der zusammengesetzten Inhaltsansicht aktualisiert wurden.
  9. Sie sicherstellen möchten, dass vor der Veröffentlichung alle Repositories:
    • Synchronisiert sind
    • Ihre letzte Synchronisierung erfolgreich abgeschlossen haben
    • Derzeit nicht synchronisieren
  10. Sie Repositories vor dem Veröffentlichen und optionalen Fördern von Inhaltsansichten / zusammengesetzten Inhaltsansichten synchronisieren möchten
  11. Sie bestimmte Repositories von Überprüfungen und/oder Synchronisation ausschließen möchten
  12. Sie auf die Beendigung von derzeit synchronisierenden Repositories warten möchten (wenn nicht über diese Rolle ausgelöst), bevor Sie Inhaltsansichten / zusammengesetzte Inhaltsansichten veröffentlichen und optional fördern.

Warum haben Sie nicht zur Red Hat-zertifizierten Sammlung / zur upstream Foreman-Ansible-Sammlung beigetragen?

Ich könnte fragen, ob so eine Rolle es wert ist, beigetragen zu werden. Sie könnte theoretisch ein drop-in Ersatz für die bestehende Rolle content_view_publish sein, ist jedoch deutlich komplexer und hat einen anderen Ansatz, wenn es um die Validierung von Daten (vom Benutzer bereitgestellt oder API) geht. Diese Rolle validiert alles, um sicherzustellen, dass an Patchtagen nichts kaputtgeht, was etwas ist, worüber ich mehr besorgt bin, als über die Ausführungsgeschwindigkeit der Rolle selbst. Sie enthält auch einige recht komplexe YAML-Multiline-Filter-Wahnsinn (obwohl meines Erachtens sehr gut kommentiert), was vielleicht etwas ist, was andere nicht mögen werden.

Ich habe diese Rolle hauptsächlich für mich selbst geschrieben, da ich sie genau so benötige. Sie könnte etwas für ein breiteres Publikum sein, aber ob das etwas ist, was Red Hat oder die Foreman-Community langfristig unterstützen möchte (selbst wenn ich mich als Wartender für diese spezielle Rolle anmelde), ist eine andere Geschichte.

Wie immer bei Open Source kann ich nicht garantieren, dass ich diese Rolle in den nächsten drei, fünf, zehn oder mehr Jahren pflegen werde, sodass ein neuer Wartender gefunden werden muss, wenn sie Teil der redhat.satellite und/oder theforeman.foreman Sammlung ist, sollte ich aus irgendwelchen Gründen verschwinden. Obwohl ich definitiv plane, diese Rolle eine geraume Zeit zu pflegen, kann ich das sicherlich nicht garantieren. Wenn sie als zu komplex erachtet wird, um von anderen gewartet zu werden, wird sie wahrscheinlich nicht in eine der Sammlungen aufgenommen.

Ehrlich gesagt: Erwarten Sie nicht zu viel, da es definitiv zu komplex ist, leider. 😢

Was diese Rolle als 'legacy'-Definition betrachtet

[^legacy]: Die Rollen redhat.satellite.content_view_publish und auch die Rolle theforeman.foreman.content_view_publish akzeptieren Inhaltsansichts-/zusammengesetzte Inhaltsansichtsdefinitionen in den folgenden Formaten:

Format eins, das ich legacy_a nenne

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

Format zwei, das ich legacy_b nenne

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

Beide Formate sind, meiner bescheidenen Meinung nach, unterdurchschnittlich.

Typischerweise, wenn es notwendig ist, ein Listenelement nach Namen zu identifizieren, wird das Attribut name verwendet - nicht etwas, das den Typ des definierten Objekts beschreibt. Besonders wenn man bedenkt, dass eine andere Rolle der gleichen Sammlungen (redhat.satellite.content_views oder theforeman.foreman.content_views) das name-Attribut erfordert.

Verstehen Sie mich nicht falsch, ich sage nicht, dass es absolut unüblich ist, das name-Attribut nicht definiert zu haben, aber ich würde argumentieren, dass es eher gängige Praxis ist, name anstelle von etwas anderem zu verwenden, wenn es darum geht, Objekte nach Namen zu identifizieren.

Das 'Liste von Strings Format' (legacy_a) ist noch restriktiver, da Sie nur eine Liste von Inhaltsansichten / zusammengesetzten Inhaltsansichten angeben können, die Sie veröffentlichen möchten. Nichts weiter, keine anderen Attribute.

Ich verstehe, warum dies als einfacher Einstieg in die Rolle erscheinen könnte, aber ehrlich gesagt, ist es nicht viel komplizierter / umständlicher, einfach ein name: vor jede Inhaltsansicht / jede zusammengesetzte Inhaltsansicht zu setzen? Ich denke nicht 😊.

Das 'korrekte' Format, das verwendet werden sollte

Letztendlich geben Sie Ihre Inhaltsansichten / zusammengesetzten Inhaltsansichten wie folgt an:

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

Das hat zwei Vorteile:

  • Sie können dieselbe Definition von Inhaltsansichten / zusammengesetzten Inhaltsansichten wie für die Rolle (redhat.satellite.content_views) verwenden
  • Sie vermeiden die Konvertierung dieser Rolle, was die Leistung erheblich verbessert

Rollenvariablen

Variable Standard Erforderlich Beschreibung
satellite_username nicht gesetzt wahr Benutzername zur Authentifizierung gegenüber der Satellite API
satellite_password nicht gesetzt wahr Passwort des Benutzers zur Authentifizierung gegenüber der Satellite API
satellite_server_url nicht gesetzt wahr URL zur Satellite API (einschließlich http/s://)
satellite_organization nicht gesetzt wahr Name der Satellite-Organisation, in der Aktionen durchgeführt werden sollen
satellite_content_views nicht gesetzt wahr Inhaltsansichten und zusammengesetzte Inhaltsansichten, die veröffentlicht und optional gefördert werden sollen
satellite_validate_certs true falsch Ob Zertifikate bei der Verbindung zur Satellite API validiert werden sollen
sat_api_timestamp_format %Y-%m-%d %H:%M:%S %Z falsch Format, in dem die Zeitstempel in der Satellite API dargestellt werden
sat_async_max_time 3600 falsch Zeit in Sekunden, die jede asynchrone Aufgabe läuft, bis sie abläuft
sat_async_poll_time 0 falsch Abfragezeit jeder asynchronen Aufgabe. Auf 0 setzen für gleichzeitige Veröffentlichen / Fördern
sat_async_retries 1200 falsch Häufigkeit, mit der eine asynchrone Aufgabe überprüft werden sollte, bis sie als fehlgeschlagen bestimmt wird
sat_async_check_delay 3 falsch Verzögerung zwischen den Überprüfungen, ob eine asynchrone Aufgabe abgeschlossen ist
sat_quiet_assert true falsch Ob die Bestätigungsanweisungen unterdrückt werden sollen
sat_check_content_views_known true falsch Überprüfen, ob alle CVs/CCVs, die über satellite_content_views definiert sind, dem Satellite bekannt sind
sat_check_synchronizing_repositories false falsch Ob nach derzeit synchronisierenden Repositories gesucht werden soll [^check_repositories]
sat_check_successful_repository_synchronization false falsch Ob überprüft werden soll, ob die letzte Synchronisation der Repositories erfolgreich war
sat_check_unsynchronized_repositories false falsch Ob nach unsynchronisierten Repositories gesucht werden soll [^check_repositories]
sat_composite_content_view_version_description Patch day YYYY-mm-dd falsch Dasselbe wie oben, aber für Versionen zusammengesetzter Inhaltsansichten.
sat_composite_content_views_allowed_lifecycle_environments nicht gesetzt falsch Einschränken der Lebenszyklusumgebungen, auf die eine Förderung erfolgen kann für CCVs.
sat_content_view_version_description Patch day YYYY-mm-dd falsch Beschreibung der Inhaltsansichtversion. Nicht die Beschreibung der Inhaltsansicht selbst.
sat_content_view_kinds both falsch Welche Arten von Inhaltsansichten verarbeitet werden sollen [^content_view_kinds]
sat_content_views_allowed_lifecycle_environments nicht gesetzt falsch Einschränken der Lebenszyklusumgebungen, auf die eine Förderung erfolgen kann für CVs.
sat_excluded_composite_content_views nicht gesetzt falsch Ausgeschlossen sind zusammengesetzte Inhaltsansichten von jeglicher Aktivität
sat_excluded_content_views nicht gesetzt falsch Ausgeschlossen sind Inhaltsansichten von jeglicher Aktivität
sat_excluded_repositories nicht gesetzt falsch Ausgeschlossen sind Repositories von allen Aktivitäten/Überprüfungen
sat_ignore_missing_needs_publish_attribute false falsch Ignorieren eines fehlenden needs_publish Attributs [^needs_publish]
sat_publish_based_on_repository nicht gesetzt falsch Ob Inhalte basierend auf dem Synchronisationsdatum des Repositories veröffentlicht werden sollen
sat_publish_based_on_component nicht gesetzt falsch Ob zusammengesetzte Inhaltsansichten basierend auf ihren enthaltenen Komponenten veröffentlicht werden sollen
sat_show_summary true falsch Ob am Ende der Rolle eine Zusammenfassung angezeigt werden soll, die alle geänderten Objekte auflistet
sat_skip_legacy_conversion false falsch Ob die konvertierung von 'legacy' CV/CCV Definitionen im Laufe der Zeit übersprungen werden soll
sat_skip_legacy_assert false falsch Deaktivieren Sie die Überprüfung, ob ein veraltetes Format konvertiert werden kann
sat_skip_assert false falsch Ob die Überprüfungsanweisungen übersprungen werden sollen, die alle Variablen prüfen (assert.yml)
sat_wait_for_repository_synchronization false falsch Ob darauf gewartet werden soll, dass Repositories ihre Synchronisation abschließen
sat_synchronize_repositories false falsch Ob die Repositories vor der Veröffentlichung synchronisiert werden sollen
sat_convert_yaml_file nicht gesetzt falsch Datei, in die die konvertierte YAML-Definition geschrieben wird (falls angefordert)
sat_convert_yaml_indent 2 falsch Wie viele Leerzeichen die konvertierte YAML haben soll
sat_convert_yaml_sort_keys false falsch Ob die Schlüssel beim Export der YAML lexikografisch sortiert werden sollen
sat_convert_yaml_explicit_start true falsch Ob ein explizites YAML-Beginn-Tag (---) zur konvertierten Datei hinzugefügt werden soll
sat_convert_yaml_explicit_end true false Ob ein explizites YAML-Ende-Tag (...) zur konvertierten Datei hinzugefügt werden soll
sat_convert_yaml_use_custom_yaml_filter true false Ob der benutzerdefinierte YAML-Filter verwendet werden soll, der mit dieser Rolle geliefert wird
sat_convert_yaml_top_key name false Ob einen bestimmten Schlüssel und Wert an den Anfang eines Diktats zu setzen, das eine CV/CCV darstellt

[^check_repositories]: Alle Repositoryüberprüfungen werden nur für Repositories durchgeführt, die in einer Inhaltsansicht (und zusammengesetzten Inhaltsansicht technisch) enthalten sind und nicht spezifisch über sat_excluded_repositories ausgeschlossen sind.

[^content_view_kinds]: Diese Variable kann entweder den Wert content_views haben, um nur Inhaltsansichten zu verarbeiten, composite_content_views, um nur zusammengesetzte Inhaltsansichten zu verarbeiten, oder both, um entweder zu verarbeiten. So können Sie die Aktivitäten auf Inhaltsansichten oder zusammengesetzte Inhaltsansichten einschränken, falls dies erforderlich ist.

[^needs_publish]: Wenn eine längere Zeitspanne (ich kenne die genaue Zeitspanne nicht) seit der letzten Aktion vergangen ist, ist das Attribut needs_publish für zusammengesetzte Inhaltsansichten leer (null). Standardmäßig zeigt diese Rolle einen Fehler an, dass das Attribut needs_publish nicht definiert ist. Mit Aktivierung der Variablen sat_ignore_missing_needs_publish_attribute werden zusammengesetzte Inhaltsansichten, die nicht das needs_publish-Attribut haben oder es auf null gesetzt ist, zu denen hinzugefügt, die veröffentlicht werden müssen. Dies deaktiviert im Wesentlichen das 'Component Based Publishing' für diese zusammengesetzten Inhaltsansichten. Alle anderen zusammengesetzten Inhaltsansichten mit einem vorhandenen und ausgefüllten needs_publishing-Attribut sind davon nicht betroffen und werden weiterhin wie gewohnt bewertet.

Hinweise

  • sat_publish_based_on_repository macht nur für Inhaltsansichten Sinn. Daher wird es für zusammengesetzte Inhaltsansichten übersprungen.
  • sat_publish_based_on_component ist nur relevant für zusammengesetzte Inhaltsansichten, da zusammengesetzte Inhaltsansichten aus einer oder mehreren Komponenten (=Inhaltsansichtversion) bestehen

Abhängigkeiten

Diese Rolle nutzt die von Red Hat zertifizierte Sammlung redhat.satellite, die in collections/requirements.yml angegeben ist.

Beispiel-Playbook

Bitte beachten Sie, dass das folgende Beispiel auch Repositories und Komponenten enthält. Dies ist nicht erforderlich und nicht wird von dieser Rolle verwendet. Diese beinhalten nur, um zu zeigen, dass Sie dieselbe Inhaltsansicht / zusammengesetzte Inhaltsansicht Definition für diese Rolle verwenden können, die Sie für redhat.satellite.content_views verwenden werden.

Komplexes Beispiel

---
- 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: 'Patch day'
    sat_composite_content_view_version_description: 'Patch day'
    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

Lizenz

GPL-2.0-or-later

Über das Projekt

Publishes and optionally promotes Content View versions and Composite Content View versions.

Installieren
ansible-galaxy install sscheib.satellite_publish_promote_content_views
GitHub Repository
Lizenz
gpl-2.0
Downloads
252
Besitzer
Software Developer, Sysadmin, Linux and Open Source enthusiast