Question: any helm chart available?

[junquero]

Is there any helm chart available to install the artemis operator instead of using the install scripts?

If not, is there any plan to generate that helm charts and publish it in https://artifacthub.io/ or any other public helm repository?

[brusdev]

There are no plans to generate helm charts but the OLM bundle is already available and there are already plans to publish the ArtemisCloud Operator in operatorhub.io as an OLM operator. Feel free to create a new issue to publish the ArtemisCloud Operator in https://artifacthub.io/ too.

[mycroft11]

That's good news, any timelines for this?

[brusdev]

@mycroft11 I should be able to provide updates on timelines the next week.

[mycroft11]

Hi @brusdev , looking forward to seeing this on operatorhub, any updates?

[gw-kamara]

@junquero - Literally just done this today
copy the yaml files listed in the deploy.sh file into your helm templates directory and you're done.

address_queue.yaml - (from the examples/address/address_queue.yaml)
artemis_single.yaml - (from examples/artemis/artemis_single.yaml)
cluster_role.yaml
cluster_role_binding.yaml
crds - (whole directory)
election_role.yaml
election_role_binding.yaml
operator.yaml
role.yaml
role_binding.yaml
service_account.yaml

[junquero]

@gw-kamara, yes, I did it too, but there are a couple of issues you have to take into account:

1. crds directory can't be under the templates directory. It has to be at the same level than the templates directory.
2. you can have two helm charts: one for cluster-wide and another for namespaced.

I have done it and I have my own helm charts running. I asked the question because if they are interested in supporting helm charts, I can provide what I did... but it looks like they are not interested in supporting it, because they prefer to support the OLM bundle.

[brusdev]

@junquero I didn't mean to discourage you. If supporting the helm charts doesn't require a big maintenance effort, feel free to create a pull request and to set me as reviewer. Any contributions is always welcome.

[junquero]

@brusdev thank you for your new approach. The point here is not creating the helm chart(s) which is a quite simple task, the important thing is to decide which helm repo is going to be published the charts. Also, to integrate the helm chart build in the build and deploy pipeline.

I will create the pull request anyway, because it is a quite simple shell script, and then you can decide what to do with it.

[teksuo]

Hi there, any news on this?

[brusdev]

@teksuo there are no plans to generate helm charts because the OLM bundle is already available and there are already plans to publish the ArtemisCloud Operator in operatorhub.io as an OLM operator but anycontributions to support helm charts is welcome.

[Stevenpc3]

We have been using helm-charts for deployment for many years. It is largely baked into out automation. The current method of deploying this operator tool is NOT very friendly or automated. Adopting OLM is also NOT something we will be able to do any time soon as it will require review and approval.

We deliver our overall tools to a customer in special environments and it requires us to have items packaged and automated as much as possible while providing config override files for different environments. We have to be "hands off" as much as possible and almost all aspects are automated. Artemis is only 1 of the 100+ services (custom and FOSS) we package as part of our very large integrated application.

We have created our own very robust Artemis helm-chart and make our own docker image that (I would love to share) has served us well over the years. We have been waiting for some "cloud" version of Artemis for a very long time and we have had to solve many issues that this repo is just now getting to and some it appears only we have solved... We would love to contribute and adopt this solution, but we cannot use it as is without extensive work.

Creating a helm-chart would allow us to start testing with this and then we can funnel back fixes and ideas and issues. There are several good options to compare a proper chart with that use operators too.

Here are a few good operators (all we use) that have helm-charts as part of their deployment offerings.

1. https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack
2. https://github.com/elastic/cloud-on-k8s/tree/main/deploy
3. https://github.com/cloudnative-pg/charts
4. https://github.com/jaegertracing/helm-charts/tree/main/charts/jaeger-operator

The general practice is to install the operator and have another chart to install the "config" that the operator uses. I get that we can make a PR, but the integration into the operator code is critical for a good solution. Just moving *.yaml files to a helm chart then doing your own thing is not great.

For the charts listed above we create our own "wrapper" or "umbrella" charts where we list thier charts as our dep. This allows us to build templates and customize our values.yamls as overrides eaiser. We likely will have to use kustomize for some like CNPG if they do not expand their options or take more PRs. ECK and kube-prom-stack are exceptional examples of highly customizable helm charts that offer operators and instances.

There are certainly CRD concerns to be had and that is covered more in the kube docs and various examples in other charts and this is not a super light load, but it would be greatly beneficial in encouraging others to adopt the tool.

Here is another reference about templating usage and how it's beneficial as part of helm-charts (could also combine with Kustomize) cloudnative-pg/charts#346 (comment)

[brusdev]

@Stevenpc3 thanks for your feedback, I see the benefits of using helm-charts and I'm not against them but there are no volunteers working on it at the moment and I don't know how they could fit in the ArtemisCloud Operator.
Could you share your Artemis helm-chart to deepen your expectations?