Initial Helm Chart implementation

kamiKAZIK commented 2 months ago

Thank you for contributing your time to the Mosquitto project!

Before you go any further, please note that we cannot accept contributions if you haven't signed the Eclipse Contributor Agreement. If you aren't able to do that, or just don't want to, please describe your bug fix/feature change in an issue. For simple bug fixes it is can be just as easy for us to be told about the problem and then go fix it directly.

Then please check the following list of things we ask for in your pull request:

[X] Have you signed the Eclipse Contributor Agreement, using the same email address as you used in your commits?
[X] Do each of your commits have a "Signed-off-by" line, with the correct email address? Use "git commit -s" to generate this line for you.
[X] If you are contributing a new feature, is your work based off the develop branch?
[X] If you are contributing a bugfix, is your work based off the fixes branch?
[X] Have you added an explanation of what your changes do and why you'd like us to include them?
[X] Have you successfully run make test with your changes locally?

Greetings, I would like to contribute this Helm Chart for Mosquitto project. I would love if anyone could review it and write down necessary fixed, if there have to be any. It would be nice and useful if the project has it's own officially supported Helm Chart to speed up deployments on Kubernetes.

jlpedrosa commented 1 month ago

@hardillb do you know if we can merge this in? it would be highly appreciated.

npdgm commented 1 week ago

Hi. I understand you went for a Statefullset instead of a Deployment because of persistence, however this comes with severe drawbacks for apps that run a single replica such as Mosquitto. I would suggest to give the user the choice to run a Deployment with strategy.type: Recreate. The problem with StatefullSet is the k8s scheduler wont restart Mosquitto on a node crash until it comes back online or is deleted. That's bad for high availability. With a Deployment, the Pod is recreated quickly. Having the right strategy type will prevent rollout issues of concurrent requests to a RWO PersistentVolume, and it is the responsibility of the CSI to prevent edge cases with crashing nodes and ensure no multiple attachments occur.

kamiKAZIK commented 1 week ago

Hi. I understand you went for a Statefullset instead of a Deployment because of persistence, however this comes with severe drawbacks for apps that run a single replica such as Mosquitto. I would suggest to give the user the choice to run a Deployment with strategy.type: Recreate. The problem with StatefullSet is the k8s scheduler wont restart Mosquitto on a node crash until it comes back online or is deleted. That's bad for high availability. With a Deployment, the Pod is recreated quickly. Having the right strategy type will prevent rollout issues of concurrent requests to a RWO PersistentVolume, and it is the responsibility of the CSI to prevent edge cases with crashing nodes and ensure no multiple attachments occur.

Maybe if I will have time this/next month, I can remove the SS and create Deployment instead.

eclipse / mosquitto

Initial Helm Chart implementation #3036