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

recursive removal of keys? #1

Open
BernhardDenner opened this issue Mar 21, 2017 · 4 comments
Open

recursive removal of keys? #1

BernhardDenner opened this issue Mar 21, 2017 · 4 comments

Comments

@BernhardDenner
Copy link
Collaborator

What about a 'remove_recursive' option for kdbkey to allow removal of the key and all subkeys if ensure => absent?

Use case

allows removal of whole sections at once

@markus2330
Copy link
Contributor

Might be useful to get rid of predefined sections. But take care that the API does not get inconsistent (between absent and present). How can someone specify that one key is present, but all others within the section are absent?

@BernhardDenner
Copy link
Collaborator Author

BernhardDenner commented Mar 21, 2017

How can someone specify that one key is present, but all others within the section are absent?

This is currently not possible and probably never might be.

It would require to something like

kdbkey { '.../path/to/section':
  ensure => present,
  purge_unmanaged_subkeys => true
}
# not removed since its a managed key
kdbkey { '.../path/to/section/setting':
  ensure => present,
  value   => 'xy'
}

The section key has to be aware of an existing 'managed' key and requires to check the catalog if such a child resource exists. I'm not sure if that can be done in an easy and good way.

A possible way could be

kdbkey { '.../path/to/section':
  ensure           => absent,
  remove_recursive => true
}
kdbkey { '.../path/to/section/the_only_setting':
  ensure  => present,
  value   => 'xy',
  require => Kdbkey['.../path/to/section']
}

The order relation between these two keys ensures, that the section is deleted first and the key created afterwards. However, this would be a hack, since this is done on each execution

However, I would consider this as an edge case for now ;)

@markus2330
Copy link
Contributor

markus2330 commented Mar 21, 2017

However, I would consider this as an edge case ;)

Yes, but such edge cases might lead to confusing behaviour and cause more harm than good. If you do not find an elegant and expected way how to handle such conflicts, its better to not provide the feature.

How is it handled in the filesystem? Does puppet allow recursive removal of files?

What about a plugin that allows to write out configuration in kdbkey syntax?
Then someone who wants to get rid of a section, can simply export the keys and copy&paste them into the puppet manifest. (might be problematic if the default config adds new keys, though)

@BernhardDenner
Copy link
Collaborator Author

Yes, but such edge cases might lead to confusing behaviour and cause more harm than good. If you do not find an elegant and expected way how to handle such conflicts, its better to not provide the feature.

Yes, its definitely a topic to think about before implementing such a feature.

How is it handled in the filesystem? Does puppet allow recursive removal of files?

Yes, there's an option for that, while keeping managed files. So probably a hint on how to implement this ;)

What about a plugin that allows to write out configuration in kdbkey syntax?

Might be an option too

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

2 participants