[bitnami/kafka] Make using Helm parameters from documentation easier

[biergit]

Name and Version

bitname/kafka-25.1.11

What is the problem this feature will solve?

Currently you provide the option to copy parameters for configuring the Helm chart. See for example here. However to my very limited knowledge it is not possible to directly use the parameters and their values in the syntax (properties-style, dot-notation) you provide with Helm. As far as I know you need to either adapt it so that you can use them with the --set option or via use of a values.yaml.

What is the feature you are proposing to solve the problem?

I would appreciate if you provide the configuration in a way that is directly usable with Helm. I would also suggest that you provide a short note on how to pass the configuration to Helm as there may be more people like me that e.g. just want a Kafka cluster running on Minikube without learning much about Helm.

What alternatives have you considered?

No response

[joancafom]

Hi @biergit

Thanks for reaching out to us with your concern. There are different ways of providing custom values for a Helm installation, one of them being the --set flag as you mentioned (in fact, little trick, you can set multiple properties in a single --set command if you concat different values with commas key1=val1,key2=val2).

I would also suggest that you provide a short note on how to pass the configuration to Helm as there may be more people like me that e.g. just want a Kafka cluster running on Minikube without learning much about Helm.

You can already have a kafka cluster running on minikube in an incredibly straightaway approach:

$ helm install my-release oci://registry-1.docker.io/bitnamicharts/kafka

From the readme section TL;DR

So I think that use case is covered 😁 . If you want to customise the default installation, you might need a little bit more context about Helm, but both a simple helm install --help command or a look over the readme sections (for instance here) would suffice in my opinion.

I think this falls under the subjective terrain, but IMHO I do consider that specifying customised installation params requires little context about Helm itself.

[biergit]

Hi @joancafom thanks for your response. I don't know if I made myself clear enough so let me try again :) You are offering configuration code in your documentation with a button that allows copying it. The text that is copied is in the format:

somekey=somevalue
anotherkey=anothervalue

So now that I have this text how am I going to use it with Helm? Are you suggesting to use --set somekey=somevalue,anotherkey=anothervalue ? If so it would be my task to transform the copied text first. If the --set syntax is what you're suggesting then I would like to just copy --set somekey=somevalue,anotherkey=anothervalue from your documentation instead. For me it would seem useful to also provide the configuration text in a yaml format so I can pass it via -f myyaml.yml to Helm. What do you think?

[github-actions[bot]]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[github-actions[bot]]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[joancafom]

Hi @biergit

Thanks for your clarification, I understand your point now :)

You are offering configuration code in your documentation with a button that allows copying it. The text that is copied is in the format:

I am really not aware of the reasoning behind this styling in some README sections (maybe historical reasons, or even GitHub not initially offering the copy-paste option in the beginning). Having said so, I've discussed it with the team and it does make sense specifying these sections using YAML syntax as you proposed so that users can easily replicate the changes.

I will create an internal task in order to review the README and implement your suggestion in the whole catalog. Nevertheless, and as this is something IMHO that is as urgent as other of our open initiatives, I highly encourage you and anyone to contribute with PRs implementing the changes, the team (and the community) will appreciate it! 😁