In short, due to limitations of AWS your chart repository index can be broken by accident. This means that it may not reflect the "real" state of your chart files in S3 bucket. Nothing serious, but can be annoying.
To workaround this, the helm s3 reindex <repo> command is available. Note:
this operation is is much more expensive than other in
this plugin.
A chart repository file structure is always flat. It cannot contain nested directories.
The number of AWS S3 requests for reindex operation depends on your repository
structure. Due to limitations of AWS S3 API you cannot list objects of the
folder under the key excluding subfolders. ListObjects only can lists objects
under the key recursively.
The plugin code makes its best to ignore subfolders, because chart repository is always flat. But still, not all cases are covered.
Imagine the worst case scenario: you have 100 chart files in your repository,
which is the bucket root. And 1 million files in the "foo-bar" subfolder, which
are not related to the chart repository. In this case the plugin have to
call ListObjects about 1000 times (1000 objects per call) to make sure it did
not miss any chart file.
By that, the golden rule is to never have subfolders in your chart repository folder.
So, there are two good options for your chart repository file structure inside S3 bucket:
-
One bucket - one repository. Create a bucket "yourcompany-charts-stable", or "yourcompany-productname-charts" and use the bucket root as your chart repository. In this case, never put any other files in that bucket.
-
One bucket - many repositories, each in separate subfolder. Create a bucket "yourcompany-charts". Create a subfolder in it for each repository you need, for example "stable" and "testing". Another option is to separate the repositories by the product or by group of services, for example "backoffice", "order-processing", etc. And again, never put any other files in the repository folder.