Closed queeno closed 9 years ago
I think this is pretty solid.
At yelp we use the defined type to our advantage so we can declare all our apis with a single (pre-existing) array.
I think this method is a bit easier to understand, drops the datacat complexity, and allows much better, real, defaults.
Using hiera to describe this, does make configuring this module easier.
Leaving to @pauloconnor for a second opinion / shipit
Hi @solarkennedy
Thanks very much for your comment and I am indeed very happy you like my changes!
I have raised another couple of pull requests (#22 and #23) and updated this one.
Uchiwa 0.3.0 has introduced some changes about config params: stat
is removed, timeout
now defaults to 5 seconds (rather than ms!) and refresh
defaults to 5 seconds (rather than 10000 ms!).
I have linked the uchiwa commit where those changes are made.
I would suggest releasing a new version of puppet-uchiwa
as soon as all these PRs get merged!
Thanks
Simon
@pauloconnor do you have an opinion? Otherwise I'm going to merge this. It does mean a refactor on our side to ensure our APIs are built in a compatible fashion.
This makes the module configuration very similar to the method I had in v0.1.1. The reason why the define was implemented was to make automatic configuration much easier. How would you see automated configuration working with this change?
I appreciate the pull request, but I'm not sure the benefits out weigh breaking compatibility.
Hi @pauloconnor
Could you please clarify what you mean by automated configuration? Do you mean exported resources in PuppetDB?
The main benefit of my approach is to define sensu API default params rather than expecting the user to declare uchiwa::api
at least once. Also, you can entirely drive uchiwa's configuration via hiera.
Another benefit is to get rid of datacat
and rely on the template
function to build uchiwa.json
.
Yea, I personally think those are all good things.
What @pauloconnor means is, at yelp we declare our backends with an array and create_resources.
That is ok, we can do the same thing, but just the other way. We'll build the hash first, and then extract an array out of it for our other things with the keys
function.
I'm sure we can do some sort of zip/flatten/merge/hash magic.
@pauloconnor I'm going to go ahead and merge this. I believe it is a better design, long-term, for this module, even though ti means some short term pain for us as we have to re-do our profile. I'll do it.
The puppet-uchiwa module doesn't produce a clean puppet run unless a user defines at least one uchiwa::api.
It would be ideal if the module could define default parameters, which the user could over write, for example by using hiera.
For these two reasons, I changed the module's current structure, replacing
uchiwa::api
with an array of hashes, passed to theinit.pp
class.In other words, what the user could achieve by declaring...:
...now they can achieve by passing an array of hashes to the uchiwa class declaration:
Or data can be overwritten by hiera:
If
$sensu_api_endpoints
is not populated when including the class, then the default params defined inparams.pp
will be used:If a hash lacks of some params, the defaults are used instead. For example, if we include the above defined uchiwa class in the puppet catalog, the nicely-indented
uchiwa.json
file will look like this:This PR introduces incompatible changes with previous versions of puppet-uchiwa. Unfortunately leaving both methods of passing the sensu API endpoint params turned out not to be a very trivial task.
Since we don't make use of it, I removed the
richardc/datacat
dependency from the module.I have also added relevant beaker tests and updated the documentation.
If this PR is merged, then #19 is superseded and can be closed without merging.