BREAKING: manage_repos is now repos_ensure (default false), version is now unused, switch to RabbitMQ's "packagecloud" repos

[wyardley]

Note: This is a pretty big changeset. I will get it passing automated tests, but I'd love code review, and would love for folks to do some more manual testing.

This is some basic cleanup, and to drop support for installing brute force based on hard-coded version (i.e., only support using the official RabbitMQ packages via the packagecloud repo (for RHEL / CentOS), and continue supporting the Debian repo directly on the rabbitmq site).

I'm not sure if having

class rabbitmq::repo::apt(
  $key_source   = 'https://www.rabbitmq.com/rabbitmq-release-signing-key.asc',
) {
  apt::source { 'rabbitmq':
[...]
    key_source   => $key_source,

(in repo/apt.pp, and the equivalent in repo/rhel.pp) is better than just using $package_gpg_key from the main scope; is there any reason not to do it that way?

Should probably do a version bump for this, but thus far have not touched the CHANGELOG or the version in metdata.json. If this gets merged in, maybe someone in the modules team could do that?

SLES support is untested, and may be broken now that we're not directly grabbing RPM for $version from the Rabbitmq site. Would appreciate suggestions / ideas about how to properly support this using the

Dropped Archlinux support.
Left in the OpenBSD stuff, which I believe should work without explicit version, but have not tested.

[wyardley]

Missed some of the unit tests locally, will work on those as well.

[wyardley]

Hopefully SLES support would still work (just not in the case of $repos_ensure), since there is an available package: https://software.opensuse.org/package/rabbitmq-server

[wyardley]

@hunner @EmilienM @DavidS Spoke with this a bit with some folks in #forge-modules on puppet community slack about this, and commented in #440, but would love to get some feedback about this if you've got a moment.

[hunner]

Looks like there is a conflict. Sounds like a 6.0.0 would be timely, so I'll give this a review and plan on merging soon :)

[hunner]

I think for deprecated parameters we can just remove the docs and comment in the code that it is deprecated.

[wyardley]

Got it. I think @DavidS had asked me to put warnings in the code; do you want those still left in (if you try to call the deprecated parameters)?

[wyardley]

@hunner: Thanks! I tried to leave it better than I found it, but there's still room for improvement, so let me know if there's stuff I can do to make this follow best practices better. I think the README now addresses your comments, let me know what you think about the gpg_key variable though.

Would love it if you have time to review the changes proposed in https://tickets.puppetlabs.com/browse/MODULES-3679 as well, and suggest whether or not using composite namevars will be feasible / practical along with prefetching. Created a PR (just to have it to reference; it's still not yet in working state or passing tests) in #504

[wyardley]

Rebased against master and squashed my earlier commits into 1.

@bastelfreak is going to suggest some changes (in a separate PR) that will restore Archlinux support. It sounds like this is low effort, as Rabbitmq is available via its package manager already.

[fatmcgav]

@hunner / @wyardley Is this any closer to being landed? Would be good to get support for the official RabbitMQ repos into EL :)

[wyardley]

@fatmcgav: not sure, and haven't had much time to devote to working on fixes for this module lately. I'll give a stab to updating this PR against recent master, but @hunner is probably in a better position to speak about the plans for this module.

[wyardley]

Ok, took a stab at getting this in at least semi-presentable shape, even though my memory is a little fuzzy on some of the details. It's now passing spec and acceptance tests (though there is no acceptance test for the repos_ensure => true case currently) - I did test manually and it seems to work.

However, taking out rabbitmq_version in params might break the logic in the commit below, I will try to work around it, but I think it could cause some weird issues unless a dependency is forced (rabbitmq::install is ordered before ::rabbitmq::config, so maybe there won't be an issue?)

ea2303f

[wyardley]

One difference is that now that repos aren't managed by default, the rmq version on Ubuntu (at least the Ubuntu 14 used in spec tests) will be lower, I think this is why one test I had that was testing if the clustering component is listening on port 25672 fails now with these changes. However, everything else works, and it's listening on 55672, so I just commented out the tests with xit for now.