Azure Backend uses hardcoded `expiration_secs`

Version

pulp-operator v2.0.0 (quay.io/pulp/pulp-operator:v2.0.0), Azure Blob backend
via object_storage_azure_secret, redirect_to_object_storage: true,
ingress_type: none.

Problem

azureSettings() writes a fixed "expiration_secs": 60 into the generated STORAGES options:

https://github.com/pulp/pulp-operator/blob/main/controllers/repo_manager/secret.go#L380

Every other Azure option in that block is taken from the object storage Secret, and neither the S3 nor the GCS block sets a URL lifetime at all, so Azure is the only backend with a hardcoded one.

With redirect_to_object_storage: true, the content app answers each request with a 302 to a SAS URL valid for 60 seconds. That is fine for package-sized content and unworkable for large artifacts: we serve installer ISOs of 5-6 GB, and a client that re-requests or resumes against the signed URL is refused with a bare 403 from Azure with no indication of the cause.

Attempts

• AZURE_URL_EXPIRATION_SECS in the custom settings ConfigMap has no effect. django-storages passes OPTIONS to the backend constructor, and the constructor argument takes precedence over the settings name.
• Editing STORAGES from the custom settings ConfigMap is not possible either: the ConfigMap contents are rendered above the operator's generated block, so anything set there is overwritten, and code that mutates STORAGES in place raises NameError because the dict does not exist yet at that point.

Impact

Redirect-to-object-storage is effectively limited to artifacts a client can fetch in under 60 seconds. Turning the redirect off is not an alternative on Azure, since the content app then calls storage.path() and every request fails with "This backend doesn't support absolute paths".

Suggested fix

Read the value from the object storage Secret, alongside the other Azure options, e.g. an optional azure-expiration-secs key defaulting to the current 60. Falling back to AZURE_URL_EXPIRATION_SECS when the user has set it would work equally well and matches what the django-storages docs mentions.

Workaround

Define STORAGES in the custom settings ConfigMap, which makes azureSettings() return early (secret.go#L350). This means restating the whole backend configuration, including account_key, in a ConfigMap unless the values are read from the environment.

...

Happy to contribute a fix in either direction!

Start in controllers/repo_manager/secret.go, especially azureSettings() around lines 350-380, and inspect how the object storage Secret values become the generated STORAGES options. Add an optional expiration setting with the existing 60-second default, then verify that the generated Azure configuration uses the configured value while other backends remain unchanged.