Add ability to specify plugins using hiera data and automatically map them to the plugin call

[NeilHanlon]

When installing multiple plugins, it's much easier and cleaner to manage their names, versions, etc in hiera than in the module (or wrapping it all in another define type).

[NeilHanlon]

@maestrodev Can you merge this, please?

[jeffgage]

@maestrodev this is a blocker for us, please merge or provide feedback.

[NeilHanlon]

@jeffgage to be honest--this plugin isn't even worth using.

After doing this PR (which I need to fix, partially), I found that all of the plugins it tries to pull down are severely out of date--and there's a lot more that needs to be fixed in it, too (for example, you have to do a ton of workarounds to get ldap working correctly, etc)

It needs to be refactored in the worst possible way. 😦 and it doesn't look like the team here is going to do it.

If I have time in the next few months, I may look into it.

[jeffgage]

@NeilHanlon thanks for your reply. To clarify, when you say this plugin isn't worth using are you referring to the entire Puppet module? Have you seen any alternatives?

We have a working Sonarqube config which is not puppetized, so I plan to simply hardcode plugin versions based on what's already working for us.

I was able to create a Hiera definition which creates a sonar.properties file whose LDAP parameters match our existing config, but it hasn't been tested yet. Should I expect other LDAP problems?

[NeilHanlon]

@jeffgage

The whole puppet module. The biggest problem as I mentioned is that the plugins it tries to install are very outdated--and you can't even update them in the web UI without the puppet module then putting the old version back on, and causing sonarqube to crash. Our solution was to just not manage plugins through the plugin--but then we ran into the next issue.

Even the ldap plugin is out of date--and if you want to manage the LDAP config using this module--you have to let it install the plugin from the maven repository--which means you're installing an out of date plugin--and it causes issues when you try to update ldap. Lovely.

I searched long and hard for either a solution to this plugin problem, or for another module that does what we want it to--and I wasn't able to find either.

As for the issues with LDAP itself--it wants you to specify the password for your bindDN in plaintext--which is a serious nogo since this code gets checked into git. So the solution is to use something like eyaml to encrypt it in the repo, where your puppet masters can decrypt it when they run. Not 100% okay, but good enough. The problem here is that to do this, you have to expose a variable for the configuration hash to your own first-party puppet module, and then combine it with the hash for the sonarqube module before passing it into your reference for the module. It's a giant (excuse my french) pain in the ass, that I'm not willing to deal with just for this plugin.

I'd love for it to work great and for me to have no issues with it, but I think the developers have made it clear that this plugin is not actively maintained, and needs a new maintainer.

I hope to have some free time in the next few weeks with which I can fork this module and make it not be.. well. dumb. When I do that, I'll make a PR on this, as well as fork it and publish it under my own name on the forge. Hopefully that will help both of us 😄