Switch from garethr/erlang->puppet/erlang

[bastelfreak]

@wyardley we cannot update the other modules because garether/erlang requires an old stdlib version. gareth doesn't maintain it anymore so we need to switch to another erlang module.

[wyardley]

Totally agree. but from what I remember when I was trying to help with #926, I kept getting a borked Erlang on CentOS, which I think is why that acceptance test is failing.

[bastelfreak]

I think our module isn't a drop-in replacement and requires some parameters and I didn't have the time yet to dig into it :(

[wyardley]

This comment in particular has a bit of context with what I was seeing
#926 (comment)

There are also some details about required versions, though I think this problem is at an even lower level than this possibly.
https://www.rabbitmq.com/which-erlang.html

By default, until the changes in #926 happen, the project defaults to repos_ensure false, which means it's typically pulling the OS vendor supplied rmq packages, which are typically a much older version. That said, as mentioned above, even erl itself was segfaulting for me in tests

I tried running acceptance test for https://github.com/voxpupuli/puppet-erlang locally, and for me, using Docker, they fail before even connecting to the host (via BEAKER_destroy=no BEAKER_setfile=centos7-64 bundle exec rake beaker) -- same issue I have with running CentOS integration tests locally for this module.

I've asked about these issues on IRC a couple times, but haven't heard from anyone who knows what's going on - may be something with my environment, but curious if this works for others.

[bastelfreak]

What about merging #926 and then dropping the erlang module dependency?

[wyardley]

What about merging #926 and then dropping the erlang module dependency?

#926 would still require it (though it might need a different erlang version), so I don't think that makes a difference one way or another; also, without the acceptance tests working properly, there will be no way to have reasonable confidence that the module actually works.

IIRC, we currently just use it in the acceptance tests, but don't include it as a module dependency -- we require the user to satisfy the erlang dependency on their own (whether using Puppet or another solution). So using the erlang module is, I think, just to handle supplying a usable erlang version for the acceptance tests itself. Ideally, the module would also have some knobs and whistles to allow the user to choose whether to include the erlang module (and with what version).

While there are a lot of different things wrong with this module, so far, I haven't seen anyone who's been able / willing to actually adopt it or do the work to get it in better shape again. The user who was helping with the PR mentioned above probably has come the closest, but doesn't seem like they're able to continue working on it. Not sure if there's a way to put out a request for help, but if no one is able / willing, maybe it makes sense to stop supporting the module?

If someone can help with the acceptance test issues I'm seeing locally, as well as help out with the erlang related issues, I'm happy to try to get #926 the rest of the way working, but without those things functioning, it will be hard.

[bastelfreak]

Hi,
I'm currently vacationing, so I don't have a lot of time to work on the module. However I checked https://www.rabbitmq.com/install-debian.html and the repo from the rabbitmq people has an erlang package>

Currently, the recommended option for installing modern RabbitMQ on Debian and Ubuntu is using apt repositories on a Cloudsmith mirror (quick start script).
The repositories provide a modern version of Erlang.

What about supporting just that? I'm just coming back to this because there was a question on Slack about it.

[wyardley]

I'm good with the general idea, just a couple thoughts

• Users may need a specific erlang version or way of installing erlang, so at least, anything that's behavior in the module vs. the integration test probably should be configurable / disableable
• I think there's a reason we didn't use the rmq distribution. reading the notes, this is "a package stripped down to only provide those components needed to run RabbitMQ". This could work, just keeping in mind the parameters above
• It may be easier to do the above along with the repos_ensure default changes; otherwise, none of the rmq repos will be installed
• Currently the main test issues are w/ CentOS, so the problem needs to be solved for CentOS as well as Debian

[bastelfreak]

@wyardley I did some digging here. CI fails on CentOS 7 because it cannot find rabbitmq-server. I was wondering why because I only switched the erlang module. It turns out that the garethr/erlang module also pulled in the EPEL7 repository. And that provides rabbitmq-erlang. Is it possible that we do not even need any erlang repo, just EPEL?

• https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/r/ has rabbitmq-* packages
• CI run on master that configures EPEL: https://github.com/voxpupuli/puppet-rabbitmq/actions/runs/9145238090/job/25143992973#step:6:464
• https://github.com/voxpupuli/puppet-rabbitmq/actions/runs/9146784765/job/25147422738?pr=955#step:6:459 failing job because package rabbitmq-server is missing

[bastelfreak]

I've the impression we don't need an erlang repo, just the EPEL repo?

[bastelfreak]

Indeed: #983 . @wyardley do you have any insights where/when/how the erlang module was used or can we really switch to the epel repo?

[wyardley]

Not sure. As you saw, it is used in the docs and fixtures, but not a hard dependency. Seems like tests are still failing? The main goal as I remember it (when puppet was still maintaining this) was to maintain people’s ability to manage Erlang dependencies in a way that worked for them (which may not be one size fits all). I’m not currently a user of Puppet, or CentOS, or RabbitMQ, so other than providing some historical context, I’m not sure what the right approach is. Also, I’ll try again now that we did modulesync update, but I’ve not been able to get the acceptance tests for basically any OS to work locally for quite some time for this module.

I’d imagine he more important thing is probably adding support for CentOS 8 vs fixing 7? Either way, we’ve already made a lot of changes; I’d rather see what we have go out vs trying to resolve all the existing problems (of which there are many).

Also I think whenever someone really is able to deal with #926 or similar, a lot of this will be changed.