Feature dynamic version and paths, solves issues #16 and #10

[joernott]

Pull request acceptance prerequisites:

• [x] Signed the CLA (if not already signed)
• [x] Rebased/up-to-date with base branch
• [x] Updated CHANGELOG.md with patch notes (if necessary)
• [x] Any relevant docs (README.markdown or inline documentation) updated (if necessary)
• [x] Updated CONTRIBUTORS (if you would like attribution)
• [x] Tests pass CI

[karmi]

Hi @joernott, we have found your signature in our records, but it seems like you have signed with a different e-mail than the one used in yout Git commit. Can you please add both of these e-mails into your Github profile (they can be hidden), so we can match your e-mails to your Github profile?

[joernott]

The commits were made on the testing VM where I had to set the user/email to the one provided by my customer. Signed the CLA with that one, too

[tylerjl]

Thanks for the contrbution, @joernott - this is on my radar and I'll review it when I get a chance. If you could, I've recently merged in some fixes for the test suite into master, so if you could update your branch with the most recent changes on the master branch it should fix the unrelated failures in travis for this PR.

[joernott]

Thanks for fixing the tests. I didn't get around to this yesterday. I merged the fixes into the feature branch.

[joernott]

Hmm, do you have any idea where else I need to define the use of stdlib apart from metadata.json and .fixtures.yml? It looks like the dependency is not pulled into the tests.

[tylerjl]

If you take a look at the acceptance tests' helper setup code you'll see that stdlib (and apt) are only copied to Debian-based nodes right now - if you need stdlib on each distro type, you can probably just change that to be a simple array of all three fixture modules.

[joernott]

@tylerjl: I finally updated the service handling for amazonlinux and ubuntu. I needed to get some test-VMs and the amazon one was a much older one than the one you were using. Maybe, we should add an amazonlinux 2018 version to the testing, I have seen, that there is a version out, but I don't know if they switched to systemd in the meantime or are still using initd. If they still use initd, I might need to add this to the logic determining the right init provider.

[tylerjl]

Hmm, I recently had to test Amazon Linux 2 in the Elasticsearch module, and it does indeed use systemd over sysv. If you take a look at the nodesets for acceptance testing in the Elasticsearch module, there's an entry for Amazon Linux 2 that outlines the testing setup.

[joernott]

As systemd is the default init service provider, we only need to do something for non-systemd versions of the distributions. I just was not sure, if they switched to systemd or not.

[joernott]

Updated to be up-to-date with master

[joernott]

Merged the upstream changes into the PR

[tylerjl]

Hey @joernott, I'm really sorry about the delay in getting around to this but part of the reason for the slow turnaround is that I wasn't really sure whether we'd be keeping the paradigm around multiple instances, and at this point it looks like we'll be pulling that out of the Elasticsearch module, so other modules like puppet-kibana probably won't support it either. I think the path forward for folks wanting to run >1 instance of Kibana or Elasticsearch will be to rely on Docker to run more than one at a time.

With regards to some of the other features in this PR (like the ability to alter user/groups), I'm happy to help get some of those pieces merged if you'd like to re-submit those as separate PRs independent of multiple instance support. If you do really need multiple instances and end up running a fork of the module, let me know and I can help out with any questions you might have, but for now I think this upstream module will just support running a single service for Kibana.