Note this email was originally sent to the incident list, but I'm following up here on the public list as this is not a security concern. On 11/21/25 8:05 AM, Francesco La Porta wrote:
I am experiencing an issue when trying to add the OpenStack-Helm repository using Helm. Running the following command: helm repo add openstack-helm https://tarballs.opendev.org/openstack/openstack-helm <https://tarballs.opendev.org/openstack/openstack-helm>
returns the following error:
Error: looks like "https://tarballs.opendev.org/openstack/openstack-helm <https://tarballs.opendev.org/openstack/openstack-helm>" is not a valid chart repository or cannot be reached: context deadline exceeded (Client.Timeout or context cancellation while reading body)
This occurs consistently and prevents me from using the OpenStack-Helm charts via Helm.
Could you please confirm if there is an ongoing issue with the repository or advise on any alternative methods to access the charts?
This is probably not an intended behavior, but is unfortunately an expected one. The issue here is an underlying artifact of using Apache2 mod_autoindex to build index.html content on the fly from data backed by OpenAFS in a directory with thousands of entries. Opening this URL with wget and my browser takes about 3 minutes and 12 seconds. OpenAFS performs poorly with many thousands of entries and to make things worse Apache is stat'ing the directory entries to include modification times and file sizes in the generated index which takes time. The good news is I think you can workaround this today using the --timeout option to `helm repo add` and the OpenStack Helm team can change how they manage their Helm repository to improve its performance. `helm repo add` has a default timeout of 2 minutes. Given my testing says fetching this data takes around 3 minutes 12 seconds I think if you set the timeout to say 5 minutes using --timeout you should be able to fetch the data (if slowly). Separately, the OpenStack Helm team needs to stop writing all of this data to a single directory. Currently there are just under 15k entries in the directory. In addition to slowness stat'ing thousands of files OpenAFS directories have a hard limit on total entries between 15k and 60k based on the lengths of the filenames. We estimate the current limit for that directory is about 32k. Instead what they should be doing instead is sharding the data into subdirectories. For example the current file at openstack/openstack-helm/nova-2025.2.0+f6be959ce.tgz could instead be stored at openstack/openstack-helm/nova/2025.2.0/nova-2025.2.0+f6be959ce.tgz then openstack/openstack-helm/index.yaml should be updated to match. Doing this will drastically cut down on the total number of entries in each directory which will improve performance and avoid the hard limits. Now I recognize that you aren't going to fix that for them, and I can't either. I think a good next step would be for you to engage with the OpenStack Helm team directly and point out that this is both problematic for you and that there is something they can do to fix it. That team lists communication options here: https://docs.openstack.org/openstack-helm/latest/readme.html#communication and you should feel free to refer to this email thread or quote it when you reach out to them. An archived version of this email should show up in https://lists.opendev.org/archives/list/service-discuss@lists.opendev.org/ shortly after you receive it. Clark