Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Azure Backend uses hardcoded `expiration_secs`

Open
  • Is something wrong?
#1,685 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 4 days

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
74/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
azure, go, kubernetes
Domain
backend, cloud

Research 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.

Written by the indexing model from the issue text.

Description

Issue Triage-Needed
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!

Dominant language
Go
Stars
88
Forks
68
Avg merge
3d 3h
Merged PRs (30d)
1

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pulp/pulp-operator

All issues in pulp/pulp-operator

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.