Awx-operator: awx stellt bereit, erstellt aber nie einen Benutzer

Eine Sache, die mir aufgefallen ist, ist, dass der Aufgabencontainer vor der Datenbank erscheint. Ist das Startskript intelligent genug, um zu warten?

NAME                   READY   STATUS              RESTARTS   AGE
awx-69bf447555-9gr92   3/3     Running             0          20s
awx-postgres-0         0/1     ContainerCreating   0          27s

Wenn ich jetzt etwas mehr über die Reihenfolge der Dinge verstehe, kann ich sehen, dass die Datenbank tatsächlich vom Operator erstellt wird, aber dass am Ende des Prozesses die Tabelle auth_user leer ist. Ich definiere tower_admin_user und tower_admin_password in meinem awx-Objekt.

Die einzige Erwähnung von tower_admin_user, die ich finden kann, befindet sich in roles/tasks/initialize.yml, was so aussieht, als ob es _früher_ von main.yml aufgenommen wurde, aber seit dieser "Lint-Bereinigung" nicht mehr: https://github.com/ ansible/awx-operator/commit/267741550f3de75a576b7feced0b7b8abf660a93

Nachdem ich die Include-Zeile wieder auskommentiert habe, erhalte ich einen Benutzer! Aber nur manchmal. Es scheint, dass der Operator nicht wirklich wartet oder prüft, ob die Datenbank verfügbar ist, bevor er versucht, die Migrationen auszuführen:

django.db.utils.OperationalError: could not translate host name \"awx-postgres\" to address: Name or service not known"

Um sicherzustellen, dass Postgres tatsächlich gestartet wurde, habe ich am Ende eine zusätzliche Aufgabe zu role/awx-operator/main.yml hinzugefügt, bevor "Überprüfe, ob die Datenbank gefüllt ist":

- name: Verify database is available
  community.kubernetes.k8s_exec:
     namespace: "{{ meta.namespace }}"
     pod: "{{ tower_pod_name }}"
     container: "{{ meta.name }}-task"
     command: >-
       bash -c "awx-manage check_db"
  register: database_avail_check
  retries: 60
  delay: 5
  ignore_errors: true
  until: "'Database Version' in database_avail_check.stdout"

Hey @howardjones hast du dieses Problem mit der neuesten Version immer noch?

Ich habe 0.6 noch nicht ausprobiert - ich verwende derzeit meinen eigenen "0.55"-Build. Ich werde bald testen, damit ich aufhören kann, meinen eigenen Fork zu verwalten!

Hi,
Ich habe das gleiche Problem, ich habe keinen Admin-Benutzer erstellt, mit und ohne tower_admin_user und tower_admin_password definiert. Getestet habe ich es am 0.6.

Danke für den Kommentar.

1. Macht es Ihnen etwas aus, eine spec Datei zu teilen, die ich zur Reproduktion beantragen kann?

2. Was liefert kubectl logs -f deployments/awx-operator -n <yournamespace> als Ausgabe für die folgende Aufgabe: https://github.com/ansible/awx-operator/blob/devel/roles/installer/tasks/initialize.yml#L16

Hinweis: auf devel (gilt nicht für 0.6.0 ) wird der tower_admin_password nicht mehr verwendet, für die ordnungsgemäße Erstellung des Addmin-Benutzerkontos kann man sich auf die README https:/ beziehen.

Auch ich konnte mich in 0.60 nicht authentifizieren. Für mich wurde kein Geheimnis erstellt, und keine Kombination aus der manuellen Erstellung eines Geheimnisses, tower_admin_password oder tower_admin_password_secret würde mich einbringen.

Protokolle zeigten, dass die Initialisierung der Benutzeraufgabe lief, aber keine Ausgabe.

Ich habe mich nicht in die DB eingeloggt, um weitere Fehler zu beheben. Ich bin gerade in den Aufgabencontainer gegangen und habe über cli einen zweiten Superbenutzer erstellt.

echo "from django.contrib.auth.models import User; User.objects.create_superuser('admin2', '[email protected]', 'longpassword')" | awx-manage shell

Erstes Feedback – die README-Datei von 0.6.0 sagt, dass das Bereitstellungsmanifest aus dem Entwicklungszweig verwendet werden soll. Sieht so aus, als hätte sich das Manifest seit dem Tagging von 0.6.0 erheblich geändert (neue apiVersion und andere Dinge).

Die Verwendung des 0.6.0-Manifests mit der 0.6.0-README-Datei hat mir jedoch eine funktionierende awx-Instanz mit einem mir bekannten Passwort gebracht!

Die Entwickler- README, die die Standardansicht in github ist, spricht über die Erstellung von Geheimnissen, die 0.6.0 jedoch nicht. Vielleicht sollte es einen Hinweis geben, um sicherzustellen, dass die Leute einen passenden Satz von README, Manifest und Git-Zweig verwenden :-) Ziemlich sicher ist das, was @BonzTM oben sieht.

@howardjones ja, andere Community-Mitglieder wurden davon gebissen.

Es ist geplant, https://github.com/ansible/awx-operator/issues/124 zu adressieren, also sollte zumindest das bereitgestellte Manifest immer auf Augenhöhe sein (und auf den tatsächlichen richtigen Operator verweisen, der mit devel übereinstimmt). ) - Auf diese Weise sollten solche Fehlanpassungen nicht mehr vorkommen.

Ich werde dieses Problem schließen, wenn das Root-Problem behoben ist, und versuchen, das oben erwähnte Problem zu beheben. Vielen Dank für die Meldung des ursprünglichen Problems!