sensu fails to start as client_port is a string. #456
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
No matter what you put as a value for $client_port the first run of sensu fails because the rendered /etc/sensu/conf.d/client.json has a string for port value. It works at the second run. The reason is that the value returned by puppet for the hash in socket is always a string whatever you put in $client_port (string or int). It works the second time because is get munged by in the insync? method in the type definition. This is why also it can work at the first run depending of the distribution. If the distribution install a valid /etc/sensu/conf.d/client.json by default, then this problem will get unnoticed (munged by insync?). Unfortunately this is not the case for centos where no such file is installed. I added the munge at every place this could be a problem. I ran the beaker tests on centos and got: Finished in 6 minutes 20 seconds (files took 1 minute 40.05 seconds to load) 16 examples, 0 failures real 8m3.775s user 0m15.046s sys 0m1.130s puppet --version -> 3.8.4, centos7
|
I've noticed that I did not run the bug when using Hiera and setting sensu::client_port like this. |
|
Reproduced the issue on CentOS 6.6, checked out this pull and re-ran, no issues. |
|
Thanks! |
jlambert121
added a commit
that referenced
this pull request
Dec 10, 2015
…_alway_a_string sensu fails to start as client_port is a string.
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related to #454 and to #453
No matter what you put as a value for $client_port the first run of
sensu fails because the rendered /etc/sensu/conf.d/client.json has a
string for port value. It works at the second run.
The reason is that the value returned by puppet for the hash in socket
is always a string whatever you put in $client_port (string or int). It
works the second time because is get munged by in the insync? method in
the type definition.
This is why also it can work at the first run depending of the
distribution. If the distribution install a valid
/etc/sensu/conf.d/client.json by default, then this problem will get
unnoticed (munged by insync?). Unfortunately this is not the case for
centos where no such file is installed.
I added the munge at every place this could be a problem. I ran the
beaker tests on centos and got:
Finished in 6 minutes 20 seconds (files took 1 minute 40.05 seconds to load)
16 examples, 0 failures
real 8m3.775s
user 0m15.046s
sys 0m1.130s
puppet --version -> 3.8.4, centos7