sscheib.satellite_publish_promote_content_views

Przegląd Wersje Wgląd

satellite_content_view_version_publish_promote

Uwaga na początku:

Ta rola jest niezwykle skomplikowana. Testowałem ją tak dobrze, jak tylko mogłem, ale na pewno nie mogę zagwarantować, że nie ma w niej błędów. Ponieważ synchronizacja repozytoriów, publikacja oraz promowanie widoków treści zmieni te obiekty w Twoim Satelicie, zachęcam do przetestowania jej przed użyciem w produkcji. Rola ta jest dostarczana "tak jak jest" i nie biorę odpowiedzialności za jakiekolwiek potencjalne katastrofalne skutki, jakie może spowodować. Proszę mieć to na uwadze i testować z migawką w Twoim Satelicie lub na systemie laboratoryjnym. Dziękuję bardzo :slightly_smiling_face:

Ta rola publikuje i opcjonalnie promuje zarówno wersje widoków treści, jak i złożonych widoków treści. Wykorzystuje certyfikowaną kolekcję Red Hat redhat.satellite.

Była testowana na następujących wersjach Satelity:

  • 6.15
  • 6.14
  • 6.13

Aby używać certyfikowanej kolekcji redhat.satellite, musisz być subskrybentem Red Hat. Jeśli nie posiadasz żadnych subskrypcji, możesz skorzystać z subskrypcji dewelopera Red Hat, która jest dostarczana bezpłatnie przez Red Hat.

Możesz również użyć kolekcji upstream theforeman.foreman, ale musiałbyś zmienić nazwy modułów z redhat.satellite na theforeman.foreman, co jednak nie było przeze mnie testowane.

Rola została napisana w taki sposób, żeby przyjmować definicję zmiennych widoków treści tak samo, jak rola redhat.satellite.content_view_publish.

Obsługuje również wspólne zmienne ról dla kolekcji redhat.satellite. Repozytorium GitHub redhat.satellite nie zawiera sekcji dotyczącej używanych zmiennych wspólnych, ale można je sprawdzić bezpośrednio w kodzie.

Wspólne zmienne ról to:

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

Powielanie tej samej definicji widoku treści, co kolekcja redhat.satellite, pozwala na zachowanie tej samej definicji YAML dla Twoich widoków treści/złożonych widoków treści, chociaż zdecydowanie zalecam migrację swojej definicji YAML do bardziej 'nowoczesnej' definicji, która jest akceptowana zarówno przez Foremana, jak i te role.

Aby ułatwić ten proces, możesz uruchomić tę rolę z tagiem convert (--tags convert), co zapisze skonwertowany plik YAML do pliku według Twojego wyboru, który również musisz określić za pomocą zmiennej sat_convert_yaml_file.

Konwersja odbywa się domyślnie za pomocą własnego filtru dostarczonego wraz z tą rolą (list_of_dicts_to_indented_yaml). Ten filtr właściwie wcięża listy o dwa miejsca, co ansible.builtin.to_nice_yaml nie robi (to jest znane ograniczenie, które zapewne nie jest łatwe do rozwiązania, jeśli się zastanawiasz). Filtr list_of_dicts_to_indented_yaml dodaje również możliwość umieszczenia konkretnego klucza i wartości na początku listy słowników (domyślnie name).

Należy pamiętać, że ten filtr nie jest przeznaczony do użytku poza tą rolą (dlatego również nadałem mu najgorszą możliwą nazwę :slightly_smiling_face:). Będzie akceptował tylko listę słowników (gdyż to jest właśnie to, co wygeneruje konwersja) i zgłosi błąd przy jakimkolwiek innym typie danych. Implementacja analizy YAML dla różnych typów danych stanowi osobny problem. Dla tego konkretnego przypadku użycia, filtr dostarczony z rolą robi świetną robotę.

Powód, dla którego zdecydowanie zalecam migrację z 'przestarzałych'[^legacy] definicji YAML, jest taki, że ta rola potrzebuje definicji w określony sposób, aby działała. Nie martw się, konwertuje ją w locie, ale wiąże się to z utratą wydajności, ponieważ musi iterować przez wszystkie definicje widoków treści/złożonych widoków treści i konwertować każdą z nich. Im większa definicja widoku treści/złożonego widoku treści, tym większy wpływ na wydajność.

Jedyną rzeczą, która nie jest akceptowana jako argument, a inne to robią, jest current_lifecycle_environment. Rola ma inne podejście, ponieważ dynamicznie ustala bieżące środowiska cyklu życia dla każdej wersji widoku treści/wersji złożonego widoku treści, więc nie wymaga tego argumentu.

Zostawienie current_lifecycle_environment zdefiniowanego w definicji widoku treści/złożonego widoku treści nie będzie przeszkadzać tej roli, ponieważ ten atrybut nigdy nie jest pobierany.

Rola dodaje niektóre atrybuty do definicji satellite_content_views (które inne role nie będą miały znaczenia):

  • patch_day_exclude: Dzięki temu możesz na stałe wykluczyć widok treści/złożony widok treści z przetwarzania. Będą to widoki treści/złożone widoki treści, które dotykasz tylko w "specjalnych przypadkach". Na przykład, gdy przeprowadzasz aktualizację Satelity :slightly_smiling_face:. Ten atrybut jest opcjonalny.
  • lifecycle_environments: Lista środowisk cyklu życia (także per widok treści/złożony widok treści), do których zostanie promowany widok treści/złożony widok treści. Ta lista może być ograniczona w razie potrzeby (zobacz sekcję zmiennych poniżej). Ten atrybut jest opcjonalny dla publikacji, ale obowiązkowy dla promowania.

Różnice w stosunku do redhat.satellite.content_view_publish

Sposób działania tej roli różni się całkowicie od działania roli redhat.satellite.content_view_publish.

Rola redhat.satellite.content_view_publish jest dosłownie prosta: Publikuj wszystkie widoki treści zdefiniowane w satellite_content_views, iterując po tej liście i publikując je. Możesz to robić asynchronicznie (async) lub jeden po drugim. Bez zbędnych dodatków. Nie zrozum mnie źle, nie ma nic złego w tej roli. Sposób jej działania to prawdopodobnie dokładnie to, co 98% użytkowników tej roli docenia.

Ja jestem jednym z 2%, którzy potrzebują czegoś więcej. Chcę, aby rola dynamicznie decydowała, które widoki treści/złożone widoki treści publikować, gdzie je promować i nawet wykluczając widoki treści/złożone widoki treści bez redefiniowania satellite_content_views. Ponadto nie chcę, aby rola publikowała nową wersję widoku treści/złożonego widoku treści, jeśli nie jest to konieczne, ponieważ nic się nie zmieniło. To samo dotyczy promowania. Powinno promować tylko w razie potrzeby i raportować status changed tylko wtedy, gdy coś naprawdę się zmieniło. Oczywiście chcę także ograniczyć środowiska cyklu życia, do których promuję - i to nie przez redefiniowanie definicji w satellite_content_views.

Brzmi zbyt dobrze, aby było prawdziwe? Cóż, w pewnym sensie tak. W tej roli zaimplementowałem wszystko, co powyżej (i więcej), ale ma to swoje minusy: złożoność i prędkość wykonania.

Starałem się obniżyć prędkość wykonania jak najniżej, ale jest znacznie wolniejsza niż redhat.satellite.content_view_publish - ale też bardziej wszechstronna.

Aby wdrożyć powyższe wymagania, technicznie musiałbym pobierać każdy widok treści/złożony widok treści jeden po drugim z API Satelity i wydobywać wymagane dane. To z pewnością można zrobić, iterując po wszystkich widokach treści/złożonych widokach treści i wykonując redhat.satellite.resource_info dla bieżącego widoku treści/złożonego widoku treści.

Możemy również zamiast tego pobrać wszystkie widoki treści/złożone widoki treści naraz i odfiltrować te, które nie są zdefiniowane w satellite_content_views. Pobieranie "wielkiej chmury" danych z API Satelity jest zwykle szybsze na mój koszt niż pobieranie małych kawałków jeden po drugim. W końcu najprawdopodobniej publikujesz i/lub promujesz wszystkie widoki treści/złożone widoki treści znajdujące się w Satellite i mogą wykluczać tylko kilka. Ostatecznie musimy pobrać większość widoków treści/złożonych widoków treści, więc czemu nie pobrać ich wszystkich od razu :slightly_smiling_face:.

Mam również tonę sprawdzeń, aby upewnić się, że zarówno dane wprowadzane do roli, jak i dane pobierane z API Satelity są takie, jak oczekiwano. Wiem, że to nie jest wyjątkowo "Ansible’owe", ale chcę mieć pewność, że wszystko jest takie, jakiego się spodziewam, co zapobiegnie niespodziewanym rezultatom.

Wszystko to sprawia, że rola jest bardzo wszechstronna, ale jednocześnie bardzo złożona. Starałem się w komentarzach do złożonych sekcji w kodzie, aby użytkownicy tej roli zrozumieli, co się dzieje.

Ale bądźmy szczerzy. Ta rola nie jest dla początkujących Ansible. Można nawet twierdzić, że większość kodu w tej roli powinna być obsługiwana przez dedykowany moduł Ansible, a to, co robię z tą rolą, to czyste szaleństwo. Możesz mieć rację. Ale także myślę, że tego rodzaju kod nie jest tak rzadki, jak można by przypuszczać. W końcu Ansible jest świetny w łączeniu różnych systemów i dlatego czasami potrzebujesz złożoności. Na nieszczęście.

Kiedy rozważyć użycie tej roli

Możesz rozważyć użycie tej roli zamiast oficjalnej redhat.satellite.content_view_publish, gdy:

  1. Chcesz promować wersje widoków treści lub wersje złożonych widoków treści podczas publikowania nowej wersji widoku treści/wersji złożonego widoku treści.
  2. Chcesz promować tylko, bez publikowania nowej wersji widoku treści lub wersji złożonego widoku treści, w sposób idempotentny.
  3. Chcesz promować, ale tylko do zdefiniowanych środowisk cyklu życia w sposób idempotentny.
  4. Musisz wykluczyć pewne widoki treści lub pewne złożone widoki treści z publikacji lub promowania podczas regularnych dni aktualizacji.
  5. Nie chcesz martwić się kolejnością, w jakiej definiujesz widoki treści lub złożone widoki treści.
  6. Chcesz 'dynamicznie' ograniczyć środowiska cyklu życia, do których promowane są wersje widoków treści, bez redefiniowania YAML dla wersji widoków treści lub wersji złożonych widoków treści. Jest to przydatne, jeśli aktualizujesz co tydzień. Ale w poniedziałki chcesz promować tylko do dev, we wtorki do qa, a w czwartki do prod.
  7. Chcesz publikować i opcjonalnie promować widok treści w oparciu o to, czy najnowsza wersja widoku treści jest starsza od daty ostatniej synchronizacji włączonych repozytoriów.
  8. Chcesz publikować i opcjonalnie promować złożone widoki treści tylko wtedy, gdy włączone komponenty (wersje widoków treści) zostały zaktualizowane od ostatniej publikacji złożonego widoku treści.
  9. Chcesz upewnić się, że przed publikacją wszystkie repozytoria są:
    • Zsynchronizowane.
    • Ukończyły swoją ostatnią synchronizację pomyślnie.
    • Nie synchronizują się w tej chwili.
  10. Chcesz zsynchronizować repozytoria przed publikowaniem i opcjonalnie promowaniem widoków treści/złożonych widoków treści.
  11. Chcesz wykluczyć pewne repozytoria z sprawdzania i/lub synchronizacji.
  12. Chcesz czekać, aż aktualnie synchronizujące się repozytoria (gdy nie są uruchamiane przez tę rolę) zakończą przed publikowaniem i opcjonalnie promowaniem widoków treści/złożonych widoków treści.

Dlaczego nie przyczyniłeś się do certyfikowanej kolekcji Red Hat/kolumny upstream Foreman Ansible?

Mogę zapytać, czy taka rola jest czymś, co warto przyczynić. Teoretycznie mogłaby być zamiennikiem dla istniejącej roli content_view_publish, ale jest znacznie bardziej skomplikowana i ma inne podejście do weryfikacji danych (dostarczonych przez użytkownika lub z API). Ta rola weryfikuje wszystko, aby upewnić się, że nic się nie zepsuje podczas dni aktualizacji, co jest czymś, o co martwię się bardziej niż prędkość wykonania roli. Zawiera także sporo dość złożonej "szaleństwa" przetwarzania YAML wielolinii (choć moim zdaniem bardzo dobrze skomentowanych), co może być czymś, co innym się nie spodoba.

Napisałem tę rolę przede wszystkim dla siebie, ponieważ potrzebuję jej dokładnie tak, jak jest. Może to być coś dla szerszej publiczności, ale to, czy to coś, co społeczność Red Hat czy Foreman będzie chciała zmierzyć w dłuższej perspektywie (nawet jeśli zapiszę się jako opiekun tej konkretnej roli), to inna sprawa.

Jak zawsze w przypadku Open Source, nie mogę zagwarantować, że będę utrzymywać tę rolę przez następne trzy, pięć, dziesięć lub więcej lat, więc należy znaleźć nowego opiekuna, gdy zostanie ona częścią kolekcji redhat.satellite i/lub theforeman.foreman, jeśli zniknę z jakiegokolwiek powodu. Choć zamierzam utrzymywać tę rolę przez dość długi czas, z całą pewnością nie mogę tego zagwarantować. Jeśli zostanie uznana za zbyt złożoną do utrzymania przez innych, prawdopodobnie nie trafi do żadnej z kolekcji.

Szczerze: nie trzymajdeśdeśdeś na to oddechu, ponieważ jest to zdecydowanie zbyt skomplikowane, niestety :pensive:.

Co ta rola uważa za przestarzałą definicję

[^legacy]: Role redhat.satellite.content_view_publish oraz także rola theforeman.foreman.content_view_publish akceptują definicje widoków treści/złożonych widoków treści w następujących formatach:

Format pierwszy, który nazywam legacy_a

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

Format drugi, który nazywam legacy_b

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

Obydwa formaty są, moim skromnym zdaniem, niewłaściwe.

Typowo, gdy istnieje potrzeba zidentyfikowania elementu listy po nazwie, używa się atrybutu name - nie czegoś, co opisuje typ obiektu, który jest zdefiniowany. Szczególnie biorąc pod uwagę, że inna rola z tej samej kolekcji (redhat.satellite.content_views lub theforeman.foreman.content_views) wymaga atrybutu name.

Nie zrozum mnie źle, nie mówię, że absolutnie nietypowe jest brak zdefiniowanego atrybutu name, ale twierdzę, że mówi się o tym, że jest to dość powszechną praktyką używać name zamiast czegokolwiek innego, gdy chodzi o identyfikację obiektów po nazwie.

Format "listy ciągów" (legacy_a) jest jeszcze bardziej ograniczony, ponieważ można podać tylko listę widoków treści/złożonych widoków treści, które chcesz opublikować. Nic więcej, żadne inne atrybuty nie są - oczywiście - możliwe. Rozumiem, dlaczego może to wydawać się łatwym sposobem na rozpoczęcie korzystania z tej roli, ale szczerze mówiąc, czy nie jest to znacznie bardziej skomplikowane/pracochłonne, aby po prostu dodać name: przed każdym widokiem treści/złożonym widokiem treści? Nie sądzę :slightly_smiling_face:.

Prawidłowy format użycia

W zasadzie, definiujesz swoje widoki treści/złożone widoki treści w ten sposób:

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

Ma to dwie zalety:

  • Możesz używać tej samej definicji widoków treści/złożonych widoków treści, co dla roli (redhat.satellite.content_views)
  • Unikasz konwersji tej roli, co znacznie poprawia wydajność

Zmienne roli

zmienna domyślna wartość wymagana opis
satellite_username nieustawiona tak Nazwa użytkownika do uwierzytelnienia w API Satelity
satellite_password nieustawiona tak Hasło użytkownika do uwierzytelnienia w API Satelity
satellite_server_url nieustawiona tak URL do API Satelity (w tym http/s://)
satellite_organization nieustawiona tak Nazwa organizacji Satelity, w której mają być podejmowane działania
satellite_content_views nieustawiona tak Widoki treści i złożone widoki treści do publikacji oraz opcjonalnego promowania
satellite_validate_certs true nie Czy weryfikować certyfikaty podczas łączenia z API Satelity
sat_api_timestamp_format %Y-%m-%d %H:%M:%S %Z nie Format, w jakim przedstawiane są znaczniki czasu w API Satelity
sat_async_max_time 3600 nie Czas w sekundach, przez jaki trwa każdy asynchroniczny proces do momentu przekroczenia limitu
sat_async_poll_time 0 nie Czas przetwarzania każdego asynchronicznego zadania. Ustaw na 0, aby umożliwić równoległą publikację/promocję
sat_async_retries 1200 nie Jak często powinno być sprawdzane, czy asynchroniczne zadanie zakończyło się "porażką"
sat_async_check_delay 3 nie Opóźnienie między każdym sprawdzaniem, czy zakończyło się asynchroniczne zadanie
sat_quiet_assert true nie Czy wyciszyć instrukcje asercji
sat_check_content_views_known true nie Sprawdź, czy wszystkie CV/CCV zdefiniowane w satellite_content_views są znane dla Satelity
sat_check_synchronizing_repositories false nie Czy sprawdzać aktualnie synchronizujące repozytoria [^check_repositories]
sat_check_successful_repository_synchronization false nie Czy sprawdzać, czy ostatnia synchronizacja repozytoriów zakończyła się pomyślnie
sat_check_unsynchronized_repositories false nie Czy sprawdzać niezsynchronizowane repozytoria [^check_repositories]
sat_composite_content_view_version_description Patch day YYYY-mm-dd nie To samo, co powyżej, ale dla wersji złożonych widoków treści.
sat_composite_content_views_allowed_lifecycle_environments nieustawiona nie Ogranicz środowiska cyklu życia, do których może dojść do promowania. Dla CCV.
sat_content_view_version_description Patch day YYYY-mm-dd nie Opis wersji widoku treści. Nie opis widoku treści samego w sobie.
sat_content_view_kinds both nie Jakie rodzaje widoków treści przetwarzać [^content_view_kinds]
sat_content_views_allowed_lifecycle_environments nieustawiona nie Ogranicz środowiska cyklu życia, do których może dojść do promowania. Dla CVs.
sat_excluded_composite_content_views nieustawiona nie Wyklucz złożone widoki treści z jakiejkolwiek aktywności
sat_excluded_content_views nieustawiona nie Wyklucz widoki treści z jakiejkolwiek aktywności
sat_excluded_repositories nieustawiona nie Wyklucz repozytoria z jakiejkolwiek aktywności/sprawdzania
sat_ignore_missing_needs_publish_attribute false nie Ignoruj brakujący atrybut needs_publish [^needs_publish]
sat_publish_based_on_repository nieustawiona nie Czy publikować widoki treści w oparciu o datę synchronizacji repozytoriów
sat_publish_based_on_component nieustawiona nie Czy publikować złożone widoki treści w oparciu o ich włączone komponenty
sat_show_summary true nie Czy pokazywać podsumowanie na końcu roli, która wylistowuje wszystkie zmienione obiekty
sat_skip_legacy_conversion false nie Czy pominąć konwersję 'przestarzałych' definicji CV/CCV w locie
sat_skip_legacy_assert false nie Wyłącz sprawdzanie, czy format przestarzały może być skonwertowany
sat_skip_assert false nie Czy pominąć instrukcje asercji, które sprawdzają wszystkie zmienne (assert.yml)
sat_wait_for_repository_synchronization false nie Czy czekać na zakończenie synchronizacji repozytoriów
sat_synchronize_repositories false nie Czy synchronizować repozytoria przed publikowaniem
sat_convert_yaml_file nieustawiona nie Plik, w którym zostanie zapisany skonwertowany plik YAML (jeśli to wymagane)
sat_convert_yaml_indent 2 nie Jakie wcięcie (liczba spacji) powinien mieć skonwertowany YAML
sat_convert_yaml_sort_keys false nie Czy sortować klucze leksykograficznie podczas eksportu YAML
sat_convert_yaml_explicit_start true nie Czy dodać explicity tag zaczynający YAML (---) do skonwertowanego pliku
sat_convert_yaml_explicit_end true nie Czy dodać explicitny tag kończący YAML (...) do skonwertowanego pliku
sat_convert_yaml_use_custom_yaml_filter true nie Czy używać własnego filtru YAML zapakowanego z tą rolą
sat_convert_yaml_top_key name nie Czy umieścić konkretny klucz i wartość na górze słownika reprezentującego CV/CCV

[^check_repositories]: Wszystkie sprawdzenia repozytoriów będą wykonywane tylko na repozytoriach, które są zawarte w widoku treści (i złożonym widoku treści technicznie) i nie są specjalnie wykluczone przez sat_excluded_repositories.

[^content_view_kinds]: Ta zmienna może mieć wartość content_views, aby przetwarzać tylko widoki treści, composite_content_views, aby przetwarzać tylko złożone widoki treści, lub both, aby przetwarzać którekolwiek z nich. W ten sposób możesz ograniczyć działania do widoków treści lub złożonych widoków treści, jeśli zajdzie taka potrzeba.

[^needs_publish]: Gdy przez dłuższy czas nie podjęto żadnej akcji (nie wiem, jak długi dokładnie), atrybut needs_publish jest pusty (null) dla złożonych widoków treści. Domyślnie ta rola zgłosi błąd, że atrybut needs_publish nie jest zdefiniowany. W przypadku włączenia zmiennej sat_ignore_missing_needs_publish_attribute złożone widoki treści, które nie mają atrybutu needs_publish lub mają go ustawiony na null, będą dodawane do widoków treści, które wymagają publikacji. To skutecznie wyłącza "publikację opartą na komponentach" dla tych złożonych widoków treści. Wszystkie inne złożone widoki treści z istniejącym i wypełnionym atrybutem needs_publishing nie są tym dotknięte i będą oceniane jak zwykle.

Uwagi

  • sat_publish_based_on_repository ma sens tylko dla widoków treści. Dlatego zostanie pominięty dla złożonych widoków treści.
  • sat_publish_based_on_component jest wadliwy tylko dla złożonych widoków treści, ponieważ składają się one z jednego lub więcej komponentów (wersji widoków treści).

Zależności

Ta rola korzysta z certyfikowanej kolekcji Red Hat redhat.satellite, która jest określona w collections/requirements.yml.

Przykładowy playbook

Proszę zauważyć, że poniższy przykład zawiera również repozytoria i komponenty. To nie jest wymagane i nie jest używane przez tę rolę. Zamieszczono je tylko, aby pokazać, że możesz użyć tej samej definicji widoku treści/złożonego widoku treści dla tej roli, którą użyjesz dla redhat.satellite.content_views.

Złożony przykład

---
- 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: 'Dzień poprawek'
    sat_composite_content_view_version_description: 'Dzień poprawek'
    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

Licencja

GPL-2.0-or-later

O projekcie

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

role rhel katello satellite
Zainstaluj
ansible-galaxy install sscheib.satellite_publish_promote_content_views
GitHub repozytorium
0 gwiazdki
0 forki
0 otwarte zgłoszenia
Licencja
gpl-2.0
Pobrania
252
Właściciel
Steffen Scheib
Software Developer, Sysadmin, Linux and Open Source enthusiast