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 sharing an example of your charts. Your approach is interesting but I'm not sure it could fit in the ArtemisCloud Operator, it seems an alternative approach to the operator pattern. While the approach of the ECK operator uses helm charts to install an operator.

Is there a way for me to make issues or requests to Artemis itself?
Sure, feel free to create new issues at https://github.com/arkmq-org/activemq-artemis-operator/issues

Of course any contributions is welcome 🙂

[Stevenpc3]

Yes, I stated above that our chart is NOT for operators.

I also showed many other good operator chat examples.

The chart I shared only shows what we currently expect to be able to customize which is good insight for even the operator.

If we can't set those things using the operator (even if there was a helm chat or not) then we would not be able to use the operator.

For contribution, I mean the Artemis code request. This is I guess what I need https://activemq.apache.org/issues

[brusdev]

@Stevenpc3 I see your point. It makes sense to me. I did a review of the settings defined at https://github.com/Stevenpc3/artemis-helm-charts/blob/main/charts/artemis/README.md#values. The operator already supports the customization of all those settings except the oAuthSidecar and the zookeeper-bitnami features by using the fields in the ActiveMQArtemis CRD, the broker-properties and the resource templates.

The oAuthSidecar is an interesting feature but we plan to externalize the web console by using hawtio-online.

How does the zookeeper-bitnami feature work? Is a zookeeper cluster shared across multiple broker clusters?

For contribution, I mean the Artemis code request. This is I guess what I need https://activemq.apache.org/issues
Indeed, it is.

[Stevenpc3]

Good to hear about the configuration. Thank you for the elaboration.

I will read more about hawtio-online and compare to oauth2-proxy. We just need to authenticate the management console and it integrates with keycloak and many others .

For zookeeper we follow https://activemq.apache.org/components/artemis/documentation/latest/ha.html and posts like https://stackoverflow.com/questions/78495784/integration-activemq-artemis-with-zookeeper-does-not-work-on-colocation with posts from Justin Bertram THE Artemis maintainer/contributor to handle "split-brain" in our 2 instance cluster. It's extremely dangerous and we need HA but cannot deploy in a 3*3 quorum due to resources. So this provides that protection.

I hope the operator provides HA and handles split -brain.

[brusdev]

I will read more about hawtio-online and compare to oauth2-proxy. We just need to authenticate the management console and it integrates with keycloak and many others .

The new Apache ActiveMQ Artemis console is based on hwatio 4 that supports generic OpenID authentication, see https://hawt.io/docs/oidc.html.

I hope the operator provides HA and handles split -brain.

ArkMQ Operator supports shared store HA that doesn't require 3*3 quorum to handle split -brain because it uses DB or FS locks, see the following tests:
https://github.com/arkmq-org/activemq-artemis-operator/blob/main/controllers/activemqartemis_jdbc_ha_test.go
https://github.com/arkmq-org/activemq-artemis-operator/blob/main/controllers/activemqartemis_rwm_pvc_ha_test.go

[jasaltvik]

@brusdev Hi, any update on your plans to deploy to operatorhub.io? Would be really cool to have a community version of this available in OpenShift 💯We are potentially planning on migrating to this one from the Red Hat one, and it would be really cool if we could just switch via operatorhub. Thanks for any updates on this

[jasaltvik]

@Msarawan Hi again, just checking what the progress is on this? I probably need to migrate during next week, and it would be awesome if I could just move over to a community operator instead of having to figure out something else.

[jasaltvik]

@Msarawan Hi again, just checking what the progress is on this? I probably need to migrate during next week, and it would be awesome if I could just move over to a community operator instead of having to figure out something else.

I assume it needs to be deployed here: https://github.com/redhat-openshift-ecosystem/community-operators-prod ?

[Msarawan]

Hello @jasaltvik , Yes, I made progress, and I’m happy to share that our upstream ArkMQ Operator is now published on operatorhub.io!
Now, users can install the ArkMQ Operator in a Kubernetes cluster with OLM by creating a simple subscription.

Regarding the community OpenShift Operators, yes — we plan to publish it on community-operators-prod as well. I’m just waiting on final confirmation from the team, and once that’s in, our operator should be available there by the end of next week.

I’ll keep you updated as soon as it’s published.

[Msarawan]

Hello @jasaltvik ,
I’m happy to share that our upstream operator has now been published and is officially available in the OpenShift OperatorHub.
You can now install it directly from the OpenShift console to test the latest upstream features and bug fixes.

[jasaltvik]

Hello @jasaltvik ,
I’m happy to share that our upstream operator has now been published and is officially available in the OpenShift OperatorHub.
You can now install it directly from the OpenShift console to test the latest upstream features and bug fixes.

Awesome! Thank you so much!