Currently there are 2 charts for rabbitmq. Until #4591, only rabbitmq-ha supported multiple replicas. Now both charts are _very_ similar. At this point work on one chart is likely either already done on the other or would need to be duplicated there. I'd like to get together and merge the charts.
Toward that effort, what features from each do we need to make sure to support in the 1 unified chart going forward:
Feature | rabbitmq | rabbitmq-ha
--------| --------- | -------------
Ingress for management port | 鈽戯笍 | #4749
Amqps | No | 鈽戯笍
Persistence | partial, but not using statefulset templates? | full with #4610
Image | bitnami | official
Affinity | customizable | soft or hard on hostname
Customizable probes | 鈽戯笍 | #4749
Additional plugin ports | No | For supported plugins
@bartimar @laghoule @etiennetremel @vtuson @novcn @Antiarchitect
As recent committers on one chart or the other, I'm interested to hear if there are any features I'm missing that are different between the two charts.
Can we all agree we'd like to only have 1 rabbitmq chart and then work from there on how we get to that?
Moving to a single Chart with all the features combined is much preferred, imho.
Feel free to assign me to PRs related to this change and I'll review them.
hi @coreypobrien - I am not sure sure that rabbitmq chart was ever designed to only support one node (that seems kind of mad). I agree that they are both similar as they are both based on the upstream example: https://github.com/rabbitmq/rabbitmq-peer-discovery-k8s/tree/master/examples/k8s_statefulsets
To merge into a single chart, instead of duplicating more features (https://github.com/kubernetes/charts/pull/4749 ) wouldn't make more sense if you made PRs to rabbitmq with what you think is missing from rabbitmq-ha.
Happy to jump on slack or hangout if that will help.
@vtuson I think we're agreeing in principle, I just saw rabbitmq-ha as the more complete so was PRing in the other direction. If #4749 merges to rabbitmq-ha, is there something missing from rabbitmq-ha that would prevent you from using it?
/cc @etiennetremel @prydonius @tompizmor @carrodher
Good call, I'm also in favor of having both merged together.
@coreypobrien actually, I don't see a problem with having multiple charts. They might look similar now (specially with your new PRs) but they might diverge again into different topologies. Having choices is always a good thing.
I understand that we might be harder for people to choose where to contribute but that is part of the beauty of open source communities :)
@vtuson While having multiple charts in the open source community is a good thing, I don't agree that having multiple in this project is anything other than confusing. Can you elaborate more on the multiple topologies? Is there a specific pair of topologies that you think are useful to implement that couldn't be implemented as two options in the same chart?
Can all of these changes please be made under unstable label/directory? Some of us are trying to use these charts in production and keeping up is becoming tiring.
Can all of these changes please be made under unstable label/directory? Some of us are trying to use these charts in production and keeping up is becoming tiring.
Unfortunately there isn't a great way to make backwards-incompatible changes obvious to users, but we do try to ensure semver is followed for the chart version. #4591 should have bumped the major version, sorry that wasn't caught. We're definitely open to other ideas around how we can make changes more visible to users.
@prydonius Possibly something like https://github.com/semantic-release/semantic-release would help.
After discussing this with @etiennetremel, we decided it makes sense to merge efforts on rabbitmq and rabbitmq-ha together and have a single chart. We'll work on getting features combined and eventually deprecating rabbitmq-ha.
@prydonius Can you elaborate on the work you think needs to be done? From the table above I was preparing to add notes to rabbitmq referring to deprecation in favor of rabbitmq-ha. I think it would be good to have a complete list of the work in one place.
@coreypobrien I think that table is a good start, @tompizmor also came up with a list of things that would need to be done. We were thinking it makes sense for the combined chart to be called rabbitmq instead of rabbitmq-ha, is there any reason you'd pick rabbitmq-ha?
@tompizmor would you mind sharing your list here?
@prydonius Since I was working off the idea the rabbitmq-ha needed no changes, I was leaning toward the least effort to get to a single supported chart.
Is there any precedent for removing a chart from this repo or will we always have 2 charts now that there are 2?
Will there be a migration path either way?
The process for deprecating a chart is outlined here: https://github.com/kubernetes/charts/blob/master/PROCESSES.md#deprecating-a-chart. The chart will always be in the repository, but marked deprecated. Given the values are quite different in the two charts, the migration path would have to be manual, but the deprecated chart can be used until that migration happens. I don't think it would make sense to try to support values from both charts as that would likely be difficult to maintain.
Sorry guys, I have been quite busy these day and it will continue for the next few weeks, if anyone want to pick this up to speed up the process, be my guest.
As I mentioned to @prydonius, apart of not using the official RabbitMQ image, I'm more than willing to merge both charts.
@etiennetremel When you say "apart of not using the official RabbitMQ image" do you mean "I think the final chart should use the bitnami image by default" or "I think the final chart should support the bitnami image as an alternative"?
I would prefer using official images for any chart, not only rabbitmq. But I understand that Bitnami bring some automation to keep the chart up to date which is also interesting, so there is a trade off to be done.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
Hey everyone! Are there any updates on the effort to merge rabbitmq and rabbitmq-ha charts? I'm in the process of adding a rabbitmq subchart in a chart I'm developing. Any suggestions as to what is the safest, most future-proof option at this point?
This issue is being automatically closed due to inactivity.
Good day, what is the status regarding merging those charts?
just ran into this.. rabbitmq-ha is what i tried first, and it worked lovely.. but i wanted to experiment with rabbitmq as well.. then i noticed that there are subtle difference between the two values.yaml and this has lead me to waste many an hours trying to get the same arguments that work with rabbitmq-ha to work with rabbitmq..
can you please either re-open this to keep this work going, or just re-sync rabbitmq from rabbitmq-ha (and preferably just get rid of one)..
there's no clear explaination why there are two charts, when rabbitmq claims to have HA features (yet hard-code the cluster-domain :-/ )
I think this kind of issues will be solved once the distributed repositories are implemented definitively, so I think it's a matter of time. In the future, you can use your favorite chart from the repository you choose, and in case there are duplications inside the same repository, the owner of the repository should provide a solution/answer.
Hi All, since it's already 2020. Is there any progress or decisions about future of RabbitMQ vs RabbitMQ-ha? Is there any sort of recommendations where should typical user go? Using RabbitMQ or -HA chart? I see some advantages in both charts but they are still quite different. Thanks!
Hi, since Helm 3 release this stable repository as we know it right now will disappear sooner than later: https://github.com/helm/charts#deprecation-timeline
In the near future, there will be different charts for the same application hosted in different registries and maintained for different people (all of them listed in the Helm hub) users should use the one that best meets their needs, but the figure of stable as a source of truth will disappear. That is what I understand for the community comments and discussion, not sure if some maintainers can add more information about this topic.
Most helpful comment
Good day, what is the status regarding merging those charts?