Add official support for CentOS 8

[kajinamit]

trafficstars

Pull Request (PR) description

This change adds official support for CentOS 8. The current logic is almost compatible except for the package name of Python 2, which is python2 in CentOS 8 while python in CentOS 7.

This Pull Request (PR) fixes the following issues

N/A

[kajinamit]

Hmm. Package installation is failing because of missing key. This is likely because two gpg keys are required[1]

[1] https://www.rabbitmq.com/install-rpm.html#package-cloud

[vox-pupuli-tasks[bot]]

Dear @kajinamit, thanks for the PR!

This is Vox Pupuli Tasks, your friendly Vox Pupuli GitHub Bot. I noticed that your pull request contains merge conflict. Can you please rebase?

You can find my sourcecode at voxpupuli/vox-pupuli-tasks

[kajinamit]

It seems archi linux job is broken. I see it's failing with the same errors in https://github.com/voxpupuli/puppet-rabbitmq/pull/924 and I'm not sure how I can fix the job, honestly.

[wyardley]

It seems archi linux job is broken.

Hi - yes, don't worry about that. It's an issue bootstrapping rabbitmqadmin, and has been there for a while now.

[kajinamit]

thanks @wyardley .

I've rebased this on the latest master. it seems merge conflict tag is not purged automatically.

I'm wondering what I can do to get this PR merged. This has been floating for a while but I'm really eager to get this(and the subsequent work to support CentOS9) because we are extensively using this for OpenStack deployment.

As I mentioned in the early reply I'm not too sure whether I should enable the repository management which likely cause problems during upgrade. If people think that is the only blocker then I can fix that.

[wyardley]

@kajinamit maybe worth reading this comment in another PR that I made the other day too https://github.com/voxpupuli/puppet-rabbitmq/issues/816#issuecomment-1454294332

High level, while I don't want to bikeshed this to death, this project doesn't have a real active maintainer right now, and so it has been hard to find someone who's able to get some of the things mentioned there working in a safe and testable way.

I do really disagree that we should be installing / managing erlang in this project, at least by default, so at a minimum, we cannot force that behavior without making it configurable and, ideally, set to false by default. That's because people may already have differing needs for which erlang version they need to manage, and / or may already be installing it, and it's important that this module first not break stuff. I'd be Ok with some more junk code to set it up in the integration test, and continue to document that the user needs to manage setting up erlang themself.

I think getting the integration tests running locally would be a good start, if you don't have those working yet; I have had struggles getting that to work recently, but it's honestly going to be very hard to do much on that if you don't have the test suite working (and exec-able into) locally.

You may be able to find some folks from vox who are able to help (esp. w/r/t getting integration tests working properly, as well as some ideas about the best way to handle the erlang dep) on their IRC channel. You could also see if there's any willingness to bump the metadata without appropriate and full working integration tests, but that's not a call I'd make on my own.

[wyardley]

If https://github.com/voxpupuli/puppet-erlang still is semi-maintained, and works(ish), one option would be to use that in the integration tests if it's not already used there, and just have it be a docs fix or optional dependency for users to use it.

[kajinamit]

@wyardley Thanks for these thoughts. these are quite valudable. Do you mind explaining what's the expected coverage of integration tests you mentioned ? I'm asking this because we already have acceptance tests, and I'd like to understand correctly what would be the missing coverage we should fill by integration tests.

While it's difficult to prepare the all supported operating system and versions and test all of these manually, I can prepare c9s box to test this. Also we actually use this module in our own CI so I'll explore the possibility to use that to test this PR.

[wyardley]

Sorry, I’m using the two terms interchangeably. Acceptance tests.

[kajinamit]

If https://github.com/voxpupuli/puppet-erlang still is semi-maintained, and works(ish), one option would be to use that in the integration tests if it's not already used there, and just have it be a docs fix or optional dependency for users to use it.

This is a really good idea, because the module support installing earlang from packagecloud. Let me explore this option.

[kajinamit]

ok it seems we have to get the new release of puppet-erlang which contains https://github.com/voxpupuli/puppet-erlang/pull/15 .

[wyardley]

ok it seems we have to get the new release of puppet-erlang which contains https://github.com/voxpupuli/puppet-erlang/pull/15 .

Sounds good. Key thing is, let's just document it vs. making it a module dependency (since it's not needed for people who bootstrap erlang on their own), or make including it optional vs. some kind of bool, but use it for setting up erlang in the acceptance test if needed.

Other thought: to keep stuff small, maybe we should release the repos_ensure: true breaking change as its own change first (to keep the PRs smaller), and then work on centos 8 / debian 10 etc. support after that?

[bastelfreak]

The release PR: https://github.com/voxpupuli/puppet-erlang/pull/19

[kajinamit]

Thanks. I just got the job passing. I'll try to find time to attempt to enable repose_ensure by default later this week.