Awx-operator: La restauration échoue si une valeur dans le déploiement a deux-points

Bonjour
il échoue également si vous avez défini des env supplémentaires dans task_extra_env et/ou web_extra_env.

la définition awx suivante :

---
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"

résultats à l'awx_object de la sauvegarde suivante :

{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}

Comme vous pouvez le voir, task_extra_env et web_extra_env ne sont pas correctement définis :

• \ des nouvelles lignes ont été supprimées
• l'indentation yaml est perdue

Salutations

Un autre problème est que la modélisation d'un dictionnaire comme celui- ci ne donne pas nécessairement un yaml valide. Par exemple

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

où test.yml a {{ bla }}

Le modèle sera dans 'extra_volumes': '- name: myvolume\n persistentVolumeClaim:\n claimName: manual-claim\n qui n'est pas un yaml équivalent, donc il échouera.

De plus, cette ligne peut également causer des problèmes : la documentation dit "_Si vous avez besoin d'une interpolation de variable dans les fichiers copiés, utilisez le module ansible.builtin.template. L'utilisation d'une variable dans le champ de contenu entraînera une sortie imprévisible._" Et en effet, si vous essayez d'écrire {'a':'b'} dans un fichier avec content partir d'une variable {"a": "b"} est écrit à la place. Je ne suis pas sûr que celui-ci cause des problèmes en ce moment, mais il vaut mieux éviter cette utilisation de content pour s'assurer que nous n'avons pas de problèmes à l'avenir.

Cela ne résout pas le deuxième scénario lorsque la spécification contient \n comme décrit ci - @Spredzy

Désolé, je l'ai probablement raté, je me suis concentré sur le premier message. Je vous en prie. Je vais y travailler.

Je ne peux pas ouvrir le problème pour le moment, car avec la dernière version, un nouveau problème m'empêche d'effectuer des tests fiables.

S'il vous plaît laissez-moi savoir si quelque chose n'est pas clair dans _ce_ numéro, j'ajouterai plus de détails si c'est le cas.

@AndrewSav un correctif a atterri pour le problème ci-dessus. (espace supplémentaire) Si vous tirez devel vous devriez être prêt à partir

Je peux reproduire le problème de nouvelle ligne que vous avez mentionné. Je vais l'examiner et rapporter mes conclusions (ou RP) ici.

@Zokormazo Pourquoi a-t-il été fermé ?

Désolé, j'aurais dû expliquer ceci en fermant :

Le problème de Colon a été corrigé sur https://github.com/ansible/awx-operator/pull/404
Espace supplémentaire sur postgres sur https://github.com/ansible/awx-operator/pull/411
Le problème des nouvelles lignes perdues a été corrigé sur https://github.com/ansible/awx-operator/pull/427

J'ai testé avec une sauvegarde comprenant des secrets tls (nouvelles lignes), une image ee privée personnalisée (identification et deux points) et tout a fonctionné pour moi.

Avez-vous un autre problème sur ce processus? N'hésitez pas à rouvrir le problème ou à en ouvrir un nouveau

Avez-vous un autre problème sur ce processus?

Non, c'est juste parce que sans l'explication ci-dessus, il n'était pas clair pourquoi il avait été fermé. C'est maintenant, merci.

Oui, désolé pour ça :)

@Zokormazo J'ai parcouru cela une fois de plus avec cela dans la spécification, je soupçonne qu'il y a toujours un problème ici.

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

L'extra_volume passé via la spécification est ajouté au déploiement (en utilisant un PVC que j'ai créé manuellement dans cet espace de noms)
Voici à quoi ressemble la spécification appliquée sur le déploiement awx d'origine :

  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

Mais il échoue au moment de la restauration :

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

Voici à quoi ressemble la spécification sur le déploiement restauré :

  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'

ressemble à @Zokormazo et @Spredzy considèrent cela comme un bloqueur de version car même si nous réparions la 4.0.1, les sauvegardes de la 4.0.0 seraient corrompues. c'est généralement une bonne idée de faire une sauvegarde avant une mise à niveau vers 4.0.1, donc si la mise à niveau échouait et que la sauvegarde était inutilisable, l'utilisateur n'aurait pas de chance

Testé avec quelques extra_envs et maintenant cela fonctionne correctement