Allow for passing in previously compiled grains to custom grain modules #47372
Conversation
ghost
self-requested a review
salt/loader.py
Outdated
| if funcs[key].__code__.co_argcount == 1: | ||
| ret = funcs[key](proxy) | ||
| parameters = list(funcs[key].__code__.co_varnames) | ||
| if funcs[key].__code__.co_argcount > 0: |
There was a problem hiding this comment.
The > 0 is not really needed. :-) Enough here if parameters:. But the whole check is also not needed (see below).
salt/loader.py
Outdated
| kwargs['proxy'] = proxy | ||
| if 'grains' in parameters: | ||
| kwargs['grains'] = grains_data | ||
| ret = funcs[key](**kwargs) |
There was a problem hiding this comment.
No need to double-check length of the co_varnames as well as no need to if/else to call funcs[key] with or without kwargs. If parameters is an empty list, kwargs stays that way too, and so the call funcs[key](**{}) equals to funcs[key]() as so:
parameters = list(funcs[key].__code__.co_varnames)
kwargs = {}
if 'proxy' in parameters:
kwargs['proxy'] = proxy
if 'grains' in parameters:
kwargs['grains'] = grains_data
ret = funcs[key](**kwargs)There was a problem hiding this comment.
good point, and it looks like you can pass an empty kwargs to a function that doesn't take any arguments, TIL
| ''' | ||
| test if current grains are passed to grains module functions that have a grains argument | ||
| ''' | ||
| self.assertEqual(self.run_function('grains.get', ['custom_grain_test']), 'itworked') |
There was a problem hiding this comment.
'cmon, Dani, use PyTest, let's drop this camel case finally! 😉 Just assert that.
There was a problem hiding this comment.
We are still using Unittests, so I am going to stick to unittests asserts until that changes.
There was a problem hiding this comment.
Actually, PyTest is now the next thing and we already running it all over the place anyway. Why would one invest in soon-to-be-dead old stuff and thus create another technical debt that will cause rewrite in the near distant future? I wouldn't do that.
doc/topics/grains/index.rst
Outdated
| For custom grains, if the function takes an argument ``grains``, then the | ||
| previously rendered grains will be passed in. Because the rest of the grains | ||
| could be rendered in any order, the only grains that can be relied upon to be | ||
| passed in are ``core`` grains. This was added in the Fluorine Release. |
There was a problem hiding this comment.
Typo. "Passed in a core grains", I believe.
There was a problem hiding this comment.
that is not correct.
There was a problem hiding this comment.
Release should not be capitalized though. ;)
|
re-run py |
doc/topics/grains/index.rst
Outdated
| For custom grains, if the function takes an argument ``grains``, then the | ||
| previously rendered grains will be passed in. Because the rest of the grains | ||
| could be rendered in any order, the only grains that can be relied upon to be | ||
| passed in are ``core`` grains. This was added in the Fluorine Release. |
There was a problem hiding this comment.
Release should not be capitalized though. ;)
doc/topics/releases/fluorine.rst
Outdated
|
|
||
| Starting in this release, if a custom grains function accepts a variable named | ||
| ``grains``, the Grains dictionary of the already compiled grains will be passed | ||
| in. Because of the non deterministic order that grains are rendered in, the |
|
re-run py |
What does this PR do?
If a grains module function accepts a variable named
grainsthen the grains dict will be passed in.What issues does this PR fix or reference?
Closes #47338
Previous Behavior
No grains are passed to custom grains modules
New Behavior
Previously compiled grains are passed into grains functions if the function accepts a variable called
grainsTests written?
Yes
Commits signed with GPG?
Yes