Closed treydock closed 5 years ago
@treydock I think docs will help but what’s the exact purpose of these parameters? Are the eventually going to populate metadata?
They populate /etc/sensu/conf.d/client.json
, is there something else they should be doing? The values are passed to sensu_client_config
type which just manages the client.json
file.
The vagrant tests in this module use this:
$client_ec2 = {
'instance-id' => 'i-2102113',
}
$client_puppet = {
'nodename' => $::fqdn,
}
$client_chef = {
'nodename' => $::fqdn,
}
$client_servicenow = {
'configuration_item' => {
'name' => 'ServiceNow test',
'os_version' => '16.04',
},
}
class { 'sensuclassic':
rabbitmq_password => 'correct-horse-battery-staple',
rabbitmq_host => '192.168.156.10',
rabbitmq_vhost => '/sensu',
subscriptions => 'all',
client_address => $ip,
client_ec2 => $client_ec2,
client_chef => $client_chef,
client_puppet => $client_puppet,
client_servicenow => $client_servicenow,
filters => $filters,
filter_defaults => $filter_defaults,
version => 'latest',
}
And generates this:
{
"client": {
"address": "192.168.156.11",
"chef": {
"nodename": "el7-client.example.com"
},
"ec2": {
"instance-id": "i-2102113"
},
"http_socket": {
},
"keepalive": {
},
"name": "el7-client.example.com",
"puppet": {
"nodename": "el7-client.example.com"
},
"safe_mode": false,
"servicenow": {
"configuration_item": {
"name": "ServiceNow test",
"os_version": "16.04"
}
},
"socket": {
"bind": "127.0.0.1",
"port": 3030
},
"subscriptions": [
"all"
]
}
}
Per the docs this seems to be the behavior that should be happening:
https://docs.sensu.io/sensu-core/1.7/reference/clients/#ec2-attributes
Are you seeing something different?
That is the exact behavior I’m seeing but it’s the same behavior I saw before with
$client_custom = {
‘ec2’ => {
'instance-id' => 'i-2102113',
},
‘puppet’ => {
'nodename' => $::fqdn,
},
‘chef’ => {
'nodename' => $::fqdn,
},
‘servicenow’ => {
'configuration_item' => {
'name' => 'ServiceNow test',
'os_version' => '16.04',
},
},
}
Producing the same client.json
Then what you're seeing exactly what I'd expect given the design of the Puppet code. Your ec2
in client_custom
should behave the same before as using client_ec2
after the change to Puppet module. Because client_custom
is a "catch all" for anything not defined as a valid property, it has to exclude keys that map to valid properties otherwise custom would end up being populated with data that would conflict with properties.
If you'd expect to see something different let me know. So far I think the only change to this module I am seeing being needed is to update documentation to reflect the behavior of client_custom
with regard to filtering out keys.
Migrating issue from https://github.com/sensu/sensu-puppet/issues/1093
Supplying a key for
sensu::client_custom
that matches a key used by a property will cause Puppet to think changes are needed as the key is filtered as since it belongs to a property.@cdenneen If you feel this is more than a documentation issue let us know.