-
Notifications
You must be signed in to change notification settings - Fork 85
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
test(pillar): use static test/salt/pillar/top.sls #238
test(pillar): use static test/salt/pillar/top.sls #238
Conversation
f1b657b
to
7fc9982
Compare
Thanks, @baby-gnu. This looks like a nice idea. This will also necessitate some changes in how the |
Thanks, it was an idea inspired by a user in SaltStack matrix room, it's not urgent. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@baby-gnu I like the idea of this PR and I reckon we could benefit from using pillars_from_directories
in various formulas. However, we've got a few situations to consider, which I've mentioned inline.
NOTE: I haven't had a chance to actually test any of the ideas suggested, yet.
pillars: | ||
top.sls: | ||
base: | ||
'*': | ||
- TEMPLATE | ||
- gentoo | ||
- define_roles |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably can avoid a dedicated test/salt/pillar/top.sls
and just adapt the same method used in other formulas under state_top
.
Some examples:
pillars: | |
top.sls: | |
base: | |
'*': | |
- TEMPLATE | |
- gentoo | |
- define_roles | |
pillars: | |
top.sls: | |
base: | |
'*': | |
- TEMPLATE | |
- define_roles | |
'G@os_family:Gentoo': | |
- gentoo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, It could be done from kitchen.yml
directly but the main point of having a dedicated top.sls
is to be able to run it outside kitchen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@baby-gnu I haven't come across this idea before -- could you give me an example of this being run outside of Kitchen? Does this also apply to the using the state_top
's top.sls
as a separate file as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea came from user colttt on SaltStack matrix room to better validate formula since salt-lint
does not cover all possible errors.
colttt uses the following command to compile the states:
salt-call --id=test-minion.example.de --local --file-root=/srv/salt/states --pillar-root=/srv/salt/pillars --retcode-passthrough state.show_sls
But it can't be done easily when the formula requires pillars.
Then, my idea is to provide all the necessary to try out a formula in two steps:
- clone the formula:
git clone https://github.com/saltstack-formulas/template-formula.git && cd template-formula
- execute the formula locally with our test pillar values:
salt-call --local --id test-minion.example.net --file-root=./ --pillar-root=./test/salt/pillar/ state.show_sls TEMPLATE
There is no point in having state_top
's top.sls
in a dedicated file too since there is no salt-call
option to select that file and I think we should avoid having one in the formula directory referenced by the --file-root
option above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@baby-gnu The example you've shared doesn't appear to work, because the TEMPLATE
pillar (i.e. pillar.example
) is not in that directory:
[ERROR ] Specified SLS 'TEMPLATE' in environment 'base' is not available on the salt master
[ERROR ] Template was specified incorrectly: False
[CRITICAL] Pillar render error: Specified SLS 'TEMPLATE' in environment 'base' is not available on the salt master
Error running 'state.show_sls': Pillar failed to render. Additional info follows:
- Specified SLS 'TEMPLATE' in environment 'base' is not available on the salt master
If I comment out the TEMPLATE
line in the newly provided top.sls
, then the state runs -- but obviously missing everything from pillar.example
(the TEMPLATE
pillar).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's an issue.
To be completely functional, the test/salt/pillar/
should contains all the required files, in which case:
- the
pillars_from_files
is no more used - the
pillar.example
is just an example and not a seed for tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I push a second commit to move testing values from pillar.example
to test/salt/pillar/TEMPLATE.sls
and remove pillars_from_files
from kitchen.yml
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@baby-gnu If we're going to attempt to use these ideas across existing formulas then that's not going to be fun to refactor. There are more formulas using pillar.example
in the CI than any other file. Due to that, it's the default value used from the ssf-formula
as well.
- 50+ formulas across the whole org.
- Around 37 formulas that are managed by the
ssf-formula
.
We can discuss the relative merits of this idea in the upcoming meeting. I'm still not quite sure what the use cases are so it would great if you could demonstrate it.
7fc9982
to
baa6674
Compare
@baby-gnu I thought I'd familiarise myself with these changes by adapting it for the A couple of things I came across so far, which are valid for this PR as well:
Line 129 in 8d506ea
Tested it out with: $ salt-call --local \
--id test-minion.example.net \
--file-root=./ \
--pillar-root=./test/salt/pillar/ \
--out=yaml \
state.show_sls salt |
You are right, I'll remove it on the final rework of this PR
I'm really not sure, I think we should keep it to avoid having a
This way, all |
eba74d7
to
c63f4d5
Compare
c63f4d5
to
759ed7a
Compare
759ed7a
to
2ef5c5e
Compare
The kitchen-salt provisionner have the `pillars_from_directories` option to recusively copy directories under target pillar root. This has 3 advantages: - simplify `kitchen.yml` - manage pillar assignment with standard salt targetting mechanism, this avoid the dedicated `gentoo` suite (it could have been done from `kitchen.yml` itself by the way) - ease the test outside kitchen by running `salt-call` directly with `--pillar-root` like: ``` salt-call --local --id test-minion.example.net \ --file-root=template-formula/ \ --pillar-root=template-formula/test/salt/pillar/ \ state.show_sls TEMPLATE ``` * pillar.example: remove settings for testing purpose. * test/salt/pillar/top.sls: limit `gentoo` pillars based on `os_family` grain. * test/salt/pillar/defaults.sls: base pillar dedicated to tests. * kitchen.yml (suites): remove the now useless `gentoo` suite. Define `pillars_from_directories` to copy them under `pillar_root`. Remove useless `pillars_from_files`. * .gitlab-ci.yml: fix gentoo suite name * .gitignore: do not ignore test pillar `top.sls`
2ef5c5e
to
9c8b67d
Compare
9c8b67d
to
5f80cf2
Compare
Thanks for the patience, @baby-gnu -- merged. Rebased your changes on the latest version of this formula (the CI instances had changed). The main notes regarding the additional commit:
|
🎉 This PR is included in version 5.0.4 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
The kitchen-salt provisionner have the
pillars_from_directories
option to recusively copy directories under target pillar root.This has 3 advantages:
simplify
kitchen.yml
manage pillar assignment with standard salt targetting mechanism, this avoid the dedicated
gentoo
suite (it could have been done fromkitchen.yml
itself by the way)ease the test outside kitchen by running
salt-call
directly with--pillar-root
like:test/salt/pillar/top.sls: limit
gentoo
pillars based onos_family
grain.kitchen.yml (suites): remove the now useless
gentoo
suite.Define an empty required
pillars
to not override statictop.sls
Define
pillars_from_directories
to copy them underpillar_root
.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
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