Awx-operator: Die Wiederherstellung schlägt fehl, wenn ein Wert in der Bereitstellung einen Doppelpunkt enthält

Hallo
es schlägt auch fehl, wenn Sie zusätzliche Umgebungen in task_extra_env und/oder web_extra_env definiert haben.

die folgende awx-Definition:

---
apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: awx
spec:
  admin_email: [email protected]
  admin_user: admin
  hostname: host.domain.tld
  ingress_tls_secret: xxx-tls
  ingress_type: Ingress
  task_extra_env: |
    - name: http_proxy
      value: "http://proxy.domain.tld:3128"
    - name: https_proxy
      value: "http://proxy.domain.tld:3128"
    - name: no_proxy
      value: "localhost,127.0.0.1,.domain.tld,.cluster.local"
  web_extra_env: |
    - name: http_proxy
      value: "http://proxy.domain.tld:3128"
    - name: https_proxy
      value: "http://proxy.domain.tld:3128"
    - name: no_proxy
      value: "localhost,127.0.0.1,.domain.tld,.cluster.local"

Ergebnisse zum awx_object des folgenden Backups:

{admin_email: [email protected], admin_user: admin, api_version: awx.ansible.com/v1beta1, create_preload_data: True, deployment_type: awx, garbage_collect_secrets: False, hostname: host.domain.tld, image_pull_policy: IfNotPresent, ingress_tls_secret: xxx-tls, ingress_type: Ingress, kind: AWX, loadbalancer_port: 80, loadbalancer_protocol: http, projects_persistence: False, projects_storage_access_mode: ReadWriteMany, projects_storage_size: 8Gi, replicas: 1, route_tls_termination_mechanism: Edge, task_extra_env: - name: http_proxyn value: http://proxy.domain.tld:3128/n- name: https_proxyn value: http://proxy.domain.tld:3128n- name: no_proxyn value: localhost,127.0.0.1,.domain.tld,.cluster.localn, task_privileged: False, web_extra_env: - name: http_proxyn value: http://proxy.domain.tld:3128/n- name: https_proxyn value: http://proxy.domain.tld:3128/n- name: no_proxyn value: localhost,127.0.0.1,.domain.tld,cluster.localn}

Wie Sie sehen, sind task_extra_env und web_extra_env nicht richtig definiert:

• \ der neuen Zeilen wurden entfernt
• yaml-Einzug geht verloren

Grüße

Ein weiteres Problem besteht darin, dass das Erstellen von Vorlagen für ein Wörterbuch wie dieses nicht unbedingt zu einer gültigen yaml führt. Z.B

- set_fact:
    bla:
      extra_volumes: |
        - name: myvolume
          persistentVolumeClaim:
            claimName: manual-claim
- template:
    src: test.yml
    dest: /full/path/to/written.txt

wobei test.yml {{ bla }}

Wird ein Template in 'extra_volumes': '- name: myvolume\n persistentVolumeClaim:\n claimName: manual-claim\n erstellen, das kein äquivalentes Yaml ist, so dass es fehlschlägt.

Darüber hinaus kann diese Zeile auch Probleme verursachen: In der Dokumentation steht "_Wenn Sie eine Variableninterpolation in kopierten Dateien benötigen, verwenden Sie das Modul ansible.builtin.template. Die Verwendung einer Variablen im Inhaltsfeld führt zu einer unvorhersehbaren Ausgabe._" Und tatsächlich, wenn Sie versuchen , {'a':'b'} in eine Datei zu schreiben, wobei content aus einer Variablen {"a": "b"} geschrieben wird. Ich bin mir nicht sicher, ob dieser spezielle jetzt Probleme verursacht, aber diese Verwendung von content besser vermieden werden, um sicherzustellen, dass wir in Zukunft keine Probleme haben.

Das behebt das zweite Szenario nicht, wenn die Spezifikation wie oben beschrieben \n enthält, sollte ich ein separates Problem öffnen? @Spredzy

Entschuldigung, ich habe es wahrscheinlich übersehen, ich habe mich auf die oberste Nachricht konzentriert. Bitte. Ich werde daran arbeiten.

Ich kann das Problem im Moment nicht öffnen, da mit der neuesten Version ein neues Problem aufgetreten ist, das mich am zuverlässigen Testen hindert.

Bitte lassen Sie mich wissen, wenn etwas in _diesem_ Problem unklar ist. Ich werde weitere Details hinzufügen, wenn dies der Fall ist.

@AndrewSav für das obige Problem ist ein Fix gelandet. (zusätzliches Leerzeichen) Wenn du devel ziehst, sollte es losgehen

Ich kann das von Ihnen erwähnte Newline-Problem reproduzieren. Ich werde es prüfen und meine Ergebnisse (oder PR) hier berichten.

@Zokormazo Warum wurde es geschlossen?

Entschuldigung, ich hätte das beim Schließen erklären sollen:

Die Sache mit dem Doppelpunkt wurde auf https://github.com/ansible/awx-operator/pull/404 behoben
Zusätzlicher Platz auf Postgres auf https://github.com/ansible/awx-operator/pull/411
Verlorene Zeilenumbrüche wurden auf https://github.com/ansible/awx-operator/pull/427 behoben

Ich habe mit einem Backup getestet, das tls-Geheimnisse (Neuzeilen), ein benutzerdefiniertes privates ee-Image (Identifikation und Doppelpunkte) enthält, und alles hat für mich funktioniert.

Haben Sie ein anderes Problem mit diesem Prozess? Zögern Sie nicht, das Problem erneut zu öffnen oder ein neues zu eröffnen

Haben Sie ein anderes Problem mit diesem Prozess?

Nein, es liegt nur daran, dass ohne die obige Erklärung nicht klar war, warum es geschlossen wurde. Jetzt ist es soweit, danke.

Ja, tut mir leid :)

@Zokormazo Ich habe das in der Spezifikation noch einmal vorliegt .

spec:
    extra_volumes: |
      - name: myvolume
        persistentVolumeClaim:
          claimName: manual-claim

Das über die Spezifikation übergebene extra_volume wird der Bereitstellung hinzugefügt (unter Verwendung eines PVCs, das ich manuell in diesem Namespace erstellt habe).
So sieht die angewendete Spezifikation in der ursprünglichen awx-Bereitstellung aus:

  spec:
    admin_email: admin<strong i="11">@localhost</strong>
    admin_user: admin
    create_preload_data: true
    development_mode: false
    extra_volumes: |
      - name: myvolume
        persistentVolumeClaim:
          claimName: manual-claim

Aber es schlägt zur Wiederherstellungszeit fehl:

yaml.scanner.ScannerError: mapping values are not allowed here\n  in \"<unicode string>\", line 217, column 66:\n     ... stentVolumeClaim:\\n    claimName: manual-claim\\n\n                                         ^\n", "module_stdout": "", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1}[0m

So sieht die Spezifikation in der wiederhergestellten Bereitstellung aus:

  spec:
    admin_email: admin<strong i="18">@localhost</strong>
    admin_password_secret: awx-admin-password
    admin_user: admin
    broadcast_websocket_secret: awx-broadcast-websocket
    create_preload_data: true
    development_mode: false
    extra_volumes: '- name: myvolume\n  persistentVolumeClaim:\n    claimName: manual-claim\n'

klingt wie @Zokormazo und @Spredzy halten dies für einen Release-Blocker, denn selbst wenn wir 4.0.1 behoben haben, wären Backups von 4.0.0 beschädigt. Es ist im Allgemeinen eine gute Idee, vor einem Upgrade auf 4.0.1 ein Backup zu erstellen. Wenn das Upgrade also fehlschlägt und das Backup nicht verwendbar ist, hat der Benutzer kein Glück

Getestet mit einigen extra_envs und jetzt funktioniert es richtig