Helm chart: Allow existing S3 config secret for the filer statefulset and the s3 deployment #5039
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What problem are we solving?
Allowing users to specify their own existing S3 configuration Kubernetes Secret via the values.yaml. Before this change, you could either enable auth and use the default secret with one admin user and one readonly user or disable auth entirely or enable auth and skip the secret creation, but there was no way to specify an existing secret. There was also an issue where the kubernetes secret and volumes/volumemounts were being created even if you didn't enable auth.
How are we solving the problem?
I've added
filer.s3.existingConfigSecret
ands3.existingConfigSecret
to values.yaml for the helm chart, so a user can specify their own s3 config with whatever name they'd like as long as it has a key calledseaweedfs-s3-secret
.Example parameters for your values.yaml to use authentication and provide your own secret:
Example existing secret with your s3 config to create an admin user and readonly user, both with credentials:
Human readable s3 config json from the
seaweedfs_s3_config
key in the above example Kubernetes secretThis is the contents of the
seaweedfs_s3_config
key in the secret above. It creates an admin user and a read only user.Full list of Changes made to facilitate this feature:
Now we only create the s3 secret
volumes
orvolumeMounts
in both the S3 Deployment and filer StatefulSet if you pass in boths3.enableAuth
orfiler.s3.enableAuth
.We will use
filer.s3.existingConfigSecret
ands3.existingConfigSecret
for the name of the S3 secret volume if they are passed in. The default value of "" will result in us choosing the default name for the secret we create.Added both existingConfigSecret values to the list of exceptions for the default s3 secret creation, meaning if either are passed in, the default s3 secret will not be created.
Changed the name of the default secret template file to match the other s3 specific files by prefixing it with
s3-
for easier maintainabilityBumped the helm chart version to
3.59.2
Added an S3 section to the README.md in the helm chart directory
How is the PR tested?
Clone the seaweedfs repo and cd into the
k8s/charts/seaweedfs
directory.First test that the default configuration still works
We start by rendering the templates with s3 and s3 auth enabled:
We can see it wrote out the expected s3-secret.yaml above. Next, we need to check the
auto-secret
dir to make sure the correct secret name is rendered in the filer's statefulset:The secretName is the default secret name 🎉
full filer-statefulset.yaml
output:
Second let's test the new use case, using an existing secret
Render the helm templates with s3 enabled, s3 auth enabled, and an existing secret:
Notice that there is no s3-secret.yaml rendered, which is expected as we provided that ourselves.
Finally, let's verify that our existing secret name was rendered out correctly:
That looks correct, as the secretName is set to mytestsecret 🎉
full filer statefulset for verification
output:
Checks