fix: generate and persist SECRET_KEY for pulpcore 3.105.13 compatibility

[lucas-benedito]

SUMMARY

pulpcore 3.105.13 removed the insecure SECRET_KEY = "SECRET" default (pulp/pulpcore#7873), causing all galaxy-ng pods to enter CrashLoopBackOff on startup:

django.core.exceptions.ImproperlyConfigured: The SECRET_KEY setting must not be empty.

The galaxy-operator previously relied on this fallback. This fix adds secret_key_configuration.yml to the common role, following the same pattern as db_fields_encryption_configuration.yml.

Behavior:

• On first install: generates a 50-character random key via lookup('password', ...), stores it in a <name>-secret-key Kubernetes Secret with ownerReferences removed (so it survives CR deletion), and merges it into pulp_combined_settings so it lands in /etc/pulp/settings.py as SECRET_KEY
• On subsequent reconciliations: reads and reuses the stored value (idempotent)
• If pulp_settings.secret_key is set in the CR spec (e.g. by the AAP installer via hub_secret_key): that value is used as-is and no Secret is created

ISSUE TYPE

• Bug, Docs Fix or other nominal change

COMPONENT NAME

• Operator

STEPS TO REPRODUCE AND EXTRA INFO

Deploy galaxy-operator with quay.io/ansible/galaxy-ng:latest (any build after 2026-09-01). All api/content/worker pods crash immediately with SECRET_KEY setting must not be empty.

[jerabekjiri]

thank you, that's exactly we need 👍

[rooftopcellist]

Pushed two follow-up commits to get CI green and finish out the backup/restore piece:

f904def — fix the CI failure. The "Store secret key secret name" task was gated on pulp_combined_settings.secret_key is not defined, but the two tasks right before it already set that value — so the condition was always false by the time it ran, secret_key_secret_name never got set, status.secretKeySecret was never written, and the backup role's dump_generated_secret.yml failed on the undefined status key on every job. Fixed by capturing "was a value provided by the user" into its own fact before anything mutates pulp_combined_settings, same separation of "secret name" vs "secret value" that db_fields_encryption_configuration.yml already uses.

That alone wasn't quite enough, though: status.secretKeySecret also wasn't declared in the Galaxy CRD's status schema, and since it's a structural OpenAPI schema, the API server would've silently pruned the field on write even with the logic fixed. Added it alongside the existing dbFieldsEncryptionSecret-style fields, plus a matching spec.secret_key_secret override (used below).

355bb63 — finish the backup/restore linkage. The goal of the second commit here was for backup/restore to preserve SECRET_KEY the same way it does for db_fields_encryption_secret, admin_password_secret, etc., but a few pieces were still missing: the name wasn't written to the GalaxyBackup CR's own status, wasn't read back on restore, and wasn't pinned into the restored CR's spec. Net effect was that SECRET_KEY continuity only worked for a restore to the same deployment name — restoring under a different GalaxyRestore.spec.deployment_name would still generate a fresh random key. Wired up the remaining pieces (status write/read on the backup CR, spec pinning in custom_resource.yml, ownerReferences cleanup on restore) following the same pattern as the other generated secrets.

CI is running now on the updated branch — will confirm once it's green.