Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't remove JSON keys by (un)setting class parameters #300

Closed
nhinds opened this issue Jan 24, 2015 · 3 comments
Closed

Can't remove JSON keys by (un)setting class parameters #300

nhinds opened this issue Jan 24, 2015 · 3 comments

Comments

@nhinds
Copy link
Contributor

nhinds commented Jan 24, 2015

If a key in a JSON file managed by sensu has been set, e.g. setting sensu::api_user to admin, it is impossible to get the puppet module to remove the key in a subsequent puppet run by changing the parameter.

I initially tried not specifying the key, which should have used the default undef value, but the JSON was not changed. Explicitly setting sensu::api_user to undef has no effect either. Setting sensu::api_user to another value does change the JSON, so it's not a problem of the file already existing.

A fairly unpleasant workaround is to SSH into my puppet-managed machine and edit the file by hand, ignoring the fact that the file permissions are read-only.

@jlambert121
Copy link
Contributor

This is a limitation of puppet < 4.0.0 where puppet doesn't have a true "undefined" and as such, the providers aren't able to determine the parameter is unset. #166 talks about this a bit more as well.

@nhinds
Copy link
Contributor Author

nhinds commented Jan 25, 2015

I would have expected the files to just be templates rather than custom types, since all of the parameters in the files can be managed by puppet-sensu. This would allow you to delete a large number of custom types and providers, plus fixing this for free - if the parameter isn't present, the template will know not to include it.

Is there a reason this module is using custom types to manage simple files?

@jamtur01
Copy link
Contributor

Because we decided to be consistent across the module and create custom types and providers for everything. It's generally best practice to do so. Indeed it's a lot cleaner and more elegant that for loops in templates. In this case I have no objection to PRs that replace some of the simple types with templates etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants