Feature/make configvalidation configurable

[mms-gianni]

We had an issue with the validation of the haproxy(1.5.8-3) configuration on Debian(7.10)
It was no able to validate as long the haproxy was running.

Starting proxy HOSTNAME: cannot bind socket [xx.xx.xx.xx:80]

[mms-gianni]

Sorry for the failed checks. I will have a look on it.

[jonnytdevops]

@mms-gianni Thanks for your efforts, they are very much appreciated.

I would personally rather like to see this functionality as a boolean, rather than a path that you set to undef to disable.

@hunner @bmjen do you have any thoughts here? Perhaps there is another underlying issues here where validation shouldn't need to be disabled?

@mms-gianni Perhaps you could give a little more background information to the problem you were having?

Thanks!

[mms-gianni]

@jonnytpuppet
Our problem was that Puppet was not able to apply the changes on the HaProxy-config. If the config changes, haProxy trys to validate the config by starting another instance of HaProxy. This fails always since the Sockets are already bound on the currently running instance.

I don't know, if it only occurs on our config or if it is a general problem. This is how we have configured our HaProxy:

listen myservice
  bind 10.0.0.1:80
  mode http
  server myservice-1 10.1.0.1:80 check
  server myservice-2 10.1.0.2:80 check

This ends in following Puppet error:
Starting proxy haproxy-1: cannot bind socket [10.0.0.1:80]

To apply changes we had to stop HaProxy prior to run Puppet agent.

Using a boolean was also my first thought. But I was not sure if the HaProxy binary is on the same place in every distribution. Adding two parameters would be a solution too. One boolean and one string. But since the config is only necessary when you want to activate the validation, I put them together.

[jonnytdevops]

How about we convert this to use a boolean, and leave the path to the binary unchanged, for now. As you say, we can always create another parameter for the actual path in the future :)

@bmjen Do you think I'm being too fussy here, or do you think a boolean would be neater, given the author's concerns about the path maybe being different on other OSes (we haven't crossed that bridge yet though)

Cheers

JT

[mms-gianni]

How about keeping the variable with a boolean and add a path variable. I think this would be the cleanest solution.

[mms-gianni]

Sorry for the commit massacre. I will squash the commits when it is ok for you.

[hunner]

@mms-gianni I wonder if it's due to #243 as it should not be trying to bind to a running port

[bmjen]

This should be validate_absolute_path

[bmjen]

@mms-gianni The errant validate_cmd execution should be addressed by #243 . Which correctly calls haproxy with a -c command and shouldn't impact your running instance.