-
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
Suggestion: add saltcheck tests for formula validation #87
Comments
Thanks for bringing this across from Slack, @mchugh19. Linking back to discussions where @javierbertoli @daks Not suggesting we should undo any work that's been done with |
If you have a formula suggestion, I don't mind adding some tests and sample commands to kick off the whole thing. FYI, in the linked slack discussion it was mentioned that the downside to saltcheck was the lack of documentation. That was cleaned up for the neon release (as well as adding a bit of functionality). So if anyone is curious you can look at the neon release notes as well as the saltcheck docs linked at the top of this issue for the new and improved docs. There may also be a blog post coming out in the saltstack blog. |
@mchugh19 This formula would be great, since it already has a fairly comprehensive In any case, even something minor would be useful. That would give us a working example to further discussions about how we want to proceed across the whole of SaltStack Formulas. To give you an idea of what I mean, you can refer back to #21 to see how we've been progressing. |
@claudekenni has supplied PR #88, so linking here so that the discussions can be kept together. There is an issue with relative imports there that needs looking into. |
I've added some saltcheck tests for the salt and cron formulas. For cron, the existing cron module didn't make it easy to parse existing entries, so the saltcheck tests for config are dependent on an upstream PR. saltstack/salt#52441 For the salt formula, I didn't support the MacOS logic in the minion test. But if anyone wants to extend, it shouldn't be difficult as it can use the same jinja logic. As you can see, saltcheck tests are very similar to states. So you can start a tst file by copying the equivalent state, using the existing jinja, and replacing the state logic with the equivalent tst syntax. |
@mchugh19 Great, thanks for these PRs. I've had an issue with #88, where I end up with this error (using The minion function caused an exception: Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/salt/minion.py", line 1660, in _thread_return
return_data = minion_instance.executors[fname](opts, data, func, args, kwargs)
File "/usr/lib/python2.7/dist-packages/salt/executors/direct_call.py", line 12, in execute
return func(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/salt/modules/saltcheck.py", line 128, in run_state_tests
scheck = SaltCheck()
File "/usr/lib/python2.7/dist-packages/salt/modules/saltcheck.py", line 301, in __init__
self.salt_lc = salt.client.Caller()
File "/usr/lib/python2.7/dist-packages/salt/client/__init__.py", line 1992, in __init__
self.sminion = salt.minion.SMinion(self.opts)
File "/usr/lib/python2.7/dist-packages/salt/minion.py", line 805, in __init__
lambda: self.eval_master(self.opts, failed=True)
File "/usr/lib/python2.7/dist-packages/tornado/ioloop.py", line 440, in run_sync
self.start()
File "/usr/lib/python2.7/dist-packages/zmq/eventloop/ioloop.py", line 162, in start
super(ZMQIOLoop, self).start()
File "/usr/lib/python2.7/dist-packages/tornado/ioloop.py", line 731, in start
raise RuntimeError("IOLoop is already running")
RuntimeError: IOLoop is already running As I've mentioned on Slack, I'm expecting this to be a misconfiguration on my side rather than something specific to I'll try out both PRs to see if I get any further. |
@myii as mentioned on slack, but to duplicate here for history, that error was corrected in saltstack/salt@f54ada1#diff-9bd5118b900e8f9910f482d1b27af666 which will be released with Neon. There aren't any salt version dependencies in saltcheck.py itself, so you should be able to use neon's file and drop it into |
Experpt from Neon release notes and docs: https://docs.saltstack.com/en/develop/topics/releases/neon.html
https://docs.saltstack.com/en/develop/ref/modules/all/salt.modules.saltcheck.html
saltcheck
can be used for formula tests as part of a CI pipeline and can also be run on machines in your environment as part of a QA validation step. Personally, I see a lot of benefit to including saltcheck-tests directories in upstream formulas, as it allows for instant testing capability without other dependencies and using a state-like yaml syntax which understands pillars. For example, validating that 100 users (defined in a pillar) are properly provisioned is trivial and clear in saltcheck, while writing the same in inspec would require duplication of the salt pillar data as well as needing inspec and its dependencies which might not be appropriate in a production environment.Example file system layout:
Tests can be run for each state by name, for all apache/saltcheck/*.tst files, or for all states assigned to the minion in top.sls. Tests may also be created with no associated state. These tests will be run through the use of saltcheck.run_state_tests, but will not be automatically run by saltcheck.run_highstate_tests.
Verify package installed:
Ensure latest package installed:
Ensure python can load boto and boto3 libraries:
common/saltcheck-tests/init.tst
Test that all users exist and have the expected ssh keys. Might be appropriate for the users formula, for example.
users/saltcheck-tests/init.tst
I'd envision having basic tests like
pkg.version
isnotNull
,service.status
isTrue
, and maybe afile.contains
isTrue
live in most formulas. Since salt already has the map.jina and pkg manager abstractions, these tests can easily be upstreamed allowing for everyone's use.The text was updated successfully, but these errors were encountered: