This allows to have multiple keys or a mix of keys and IP ...
PR progress checklist (to be filled in by reviewers)
[ ] Changes to documentation are appropriate (or tick if not required)
[ ] Changes to tests are appropriate (or tick if not required)
[ ] Reviews completed
What type of PR is this?
Primary type
[ ] [build] Changes related to the build system
[ ] [chore] Changes to the build process or auxiliary tools and libraries such as documentation generation
[ ] [ci] Changes to the continuous integration configuration
[x] [feat] A new feature
[ ] [fix] A bug fix
[ ] [perf] A code change that improves performance
[ ] [refactor] A code change that neither fixes a bug nor adds a feature
[ ] [revert] A change used to revert a previous commit
[ ] [style] Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)
Secondary type
[x] [docs] Documentation changes
[ ] [test] Adding missing or correcting existing tests
Does this PR introduce a BREAKING CHANGE?
No.
Related issues and/or pull requests
Describe the changes you're proposing
Up to now allow-update, allow just one key but in some setup there is actually multiple keys. The change makes it
possible to have either just one key as a string or a 1 element list or n element list.
This means that current pillar are not impacted
Pillar / config required to test the proposed changes
allow-update:
- "key core_dhcp" # Who we allow updates, could be a string or an array
- "key other_dhcp"
Debug log showing how the proposed changes work
Documentation checklist
[ ] Updated the README (e.g. Available states).
[x] Updated pillar.example.
Testing checklist
[ ] Included in Kitchen (i.e. under state_top).
[ ] Covered by new/existing tests (e.g. InSpec, Serverspec, etc.).
This allows to have multiple keys or a mix of keys and IP ...
PR progress checklist (to be filled in by reviewers)
What type of PR is this?
Primary type
[build]
Changes related to the build system[chore]
Changes to the build process or auxiliary tools and libraries such as documentation generation[ci]
Changes to the continuous integration configuration[feat]
A new feature[fix]
A bug fix[perf]
A code change that improves performance[refactor]
A code change that neither fixes a bug nor adds a feature[revert]
A change used to revert a previous commit[style]
Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)Secondary type
[docs]
Documentation changes[test]
Adding missing or correcting existing testsDoes this PR introduce a
BREAKING CHANGE
?No.
Related issues and/or pull requests
Describe the changes you're proposing
Up to now allow-update, allow just one key but in some setup there is actually multiple keys. The change makes it possible to have either just one key as a string or a 1 element list or n element list. This means that current pillar are not impacted
Pillar / config required to test the proposed changes
Debug log showing how the proposed changes work
Documentation checklist
README
(e.g.Available states
).pillar.example
.Testing checklist
state_top
).Additional context