helm chart for transfer.sh

[beyondszine]

Hi there, This pull request tries to add helm chart feature for transfer.sh. I have currently deployed this chart in my testing cluster. Let me know in case of any changes required.

[paolafrancesca]

hi @beyondszine thanks for the PR, it is really welcome

anyway I cannot merge as it is with default S3 provider: we should provide proper switch in the values.yaml to generate the template for any provider type (local, s3 and gdrive)

let me know if you have time to do it otherwise I will do as soon I'll have time based on your branch

thanks

[beyondszine]

hi @beyondszine thanks for the PR, it is really welcome

anyway I cannot merge as it is with default S3 provider: we should provide proper switch in the values.yaml to generate the template for any provider type (local, s3 and gdrive)

let me know if you have time to do it otherwise I will do as soon I'll have time based on your branch

thanks

For sure. It makes sense.
I will update the chart for getting it executed on user's choice provided in values.yaml file.

Also, I want to ask your opinion on a few things.

1. The mechanism to provide the binary's args. As of now I thought of them as being secrets ( because of AWS_ACCESS_KEY ..etc). Will that be okay for future cases too? or somethings are seen better as configMaps ?

2. Is there a convention for replacing hyphens to underscores for params name ? ex- aws-access-key => AWS_ACCESS_KEY

3. All Other params here that are to be provided to transfersh binary can be provided by the mechanism as asked in point 1 above too. So, can there be a convention that all the params are only usable by binary if you put them in corresponding secret/configMap? This way, every param value can be found in secret by following some mapping mechanism. Ex- http-auth-user param will be automatically fetched if there is a value in secret by the key of http-auth-user | upper | replace hyphens by underscores | quote

I asked above points because this way, may be a very general helm template can be made to inject param values(if they follow some standard) from values.yaml file. Let me know of your suggestions on the same.

--

[beyondszine]

hi @beyondszine thanks for the PR, it is really welcome anyway I cannot merge as it is with default S3 provider: we should provide proper switch in the values.yaml to generate the template for any provider type (local, s3 and gdrive) let me know if you have time to do it otherwise I will do as soon I'll have time based on your branch thanks

For sure. It makes sense. I will update the chart for getting it executed on user's choice provided in values.yaml file.

Also, I want to ask your opinion on a few things.

1. The mechanism to provide the binary's args. As of now I thought of them as being secrets ( because of AWS_ACCESS_KEY ..etc). Will that be okay for future cases too? or somethings are seen better as configMaps ?

Added support for both. values.yaml file contains .Values.argValues.source.type can be secretKeyRef or configMapKeyRef

2. Is there a convention for replacing hyphens to underscores for params name ? ex- aws-access-key => AWS_ACCESS_KEY

Added as there comes some issues for hyphens in some shells with env vars.

3. All Other params here that are to be provided to transfersh binary can be provided by the mechanism as asked in point 1 above too. So, can there be a convention that all the params are only usable by binary if you put them in corresponding secret/configMap? This way, every param value can be found in secret by following some mapping mechanism. Ex- http-auth-user param will be automatically fetched if there is a value in secret by the key of http-auth-user | upper | replace hyphens by underscores | quote

All the values in given by user at .Values.argValues.paramNames in values.yaml will be fetched, converted to secret/configMap name & injected in container at runtime.

Let me know your views on above points.

I asked above points because this way, may be a very general helm template can be made to inject param values(if they follow some standard) from values.yaml file. Let me know of your suggestions on the same.

--

[paolafrancesca]

@beyondszine thank you for your effort. I will try to review and give proper feedback by the end of the week

[beyondszine]

@beyondszine thank you for your effort. I will try to review and give proper feedback by the end of the week

Sure thing.