Fix #46 (SUP-2384)

[MartyEwings]

#46

Prior to this commit on some deployments of the exporter class on a postgres node, resource ordering meant that default postgres users and groups where selected instead of the puppet_enterprise defaults

[puppet-community-rangefinder]

rsan::exporter is a class

that may have no external impact to Forge modules.

This module is declared in 0 of 576 indexed public Puppetfiles.

---

These results were generated with Rangefinder, a tool that helps predict the downstream impact of breaking changes to elements used in Puppet modules. You can run this on the command line to get a full report.

Exact matches are those that we can positively identify via namespace and the declaring modules' metadata. Non-namespaced items, such as Puppet 3.x functions, will always be reported as near matches only.

[dylanratcliffe]

@MartyEwings how have you acceptance tested this? I have a feeling that this could behave differently in the following scenarios:

• Classified with rsan::exporter using a node group
• Classified with rsan::exporter using static node declaration in site.pp

Sometimes it can be possible for custom classes to be evaluated before the puppet_enterprise code which can mean that doing things like this will fail

[MartyEwings]

It's been tested on a couple of installs on different versions, all node group based, but thats how rsan is to be installed.

Problem was without this, it picks up the defaults from pe_postgres, sometimes which is wrong.

I could always define my own params but that seems redundant

[dylanratcliffe]

IMO having a module make assumptions about how it's going to be classified is poor practice, people should be able to use node groups, existing roles/profiles, or any other method to classify the class and it should be able to work fine. Maybe the best compromise would be to expose these values as parameters on the class but have them default to what they are set to currently. That way if someone is doing something strange or custom, they can still get it working without a code change

[MartyEwings]

IMO having a module make assumptions about how it's going to be classified is poor practice, people should be able to use node groups, existing roles/profiles, or any other method to classify the class and it should be able to work fine. Maybe the best compromise would be to expose these values as parameters on the class but have them default to what they are set to currently. That way if someone is doing something strange or custom, they can still get it working without a code change

Sounds like a plan, ill push the changes

[MartyEwings]

I decided to statically define some default params, the dynamic calls to PE was gonna cause more problems that it hoped to solve