more flexible service require

[Micsi]

This makes the recently merged service-require PR #615 work better with externally managed config-files, even stored in unusual places as well as with user-specified packages. See discussion with original author at PR #615.
Works well with package-manage param PR #617
This is sort of an alternative to PR #630

[hunner]

Could you conditionalize the File[$mysql::server::config_file] dependency on $mysql::server::manage_config_file (see #630 for example)

[Micsi]

@hunner:
Why should we? Pls see the discussion on this at #630? In the proposed form it works well with a externally manged config files. I think this is the better alternative because MySQL still requires a config file to start.
This form of the require ensures that the config exists, when the server starts but even allows not standard locations of the file.
Because of this, this PR is an alternative to #630.

[Micsi]

@mhaskel I did the rebase and pushed the results. Who is responsible to remove the "needs-rebase" label?

[underscorgan]

@Micsi I think something went wrong with your rebase ... there aren't any commits there from you anymore and the PR is showing no changes

[hunner]

It looks like the rebase went wonky? There are now no lines changed. Try this:

git checkout service-require
git reset --hard 6c48b1c
git checkout master
git remote add puppetlabs https://github.com/puppetlabs/puppetlabs-mysql.git
git remote update
git reset --hard puppetlabs/master
git checkout service-require
git rebase master

< fix your merge conflict here, then git add manifests/server/service.pp to add the changes >

git rebase --continue
git push -f origin service-require

And that should get this PR up to date with only one commit, no merge conflicts, and the changes you want.

[underscorgan]

Actually, it looks like this PR won't actually fix the same usecase as #630. If $manage_config_file is set to false this will be adding dependencies on resources that likely don't exist.

[Micsi]

@mhaskel what added dependencies do you think of?
MySQL needs a config file in place to start. manage_config_file tells the module to mange it or not. The dependency to the config file has nothing to do with that, it is required anyway. With this PR the user is free to mange the config outside of the module and to store it in unusable places and still use the module service.

I for example want to copy an existing config file over to the server and use the module service. To require the config to exist before starting the machine is correct.

I think the management of the config file has nothing to do with the service. My version covers most use cases for configs.

[underscorgan]

@Micsi We think something more along the lines of #630 is better, just not adding that dependency if the config file isn't being managed. If the config file is being managed externally, there should probably be a before => Service['mysqld'] where the file is being managed, rather than the require in the service.

[Micsi]

ok then. I'll do as you say ;-)

[igalic]

@Micsi any updates here?

[Micsi]

sorry, not yet. Will push requested changes asap.

[igalic]

thank you everyone! this was fixed in #672