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

Allow for passing in previously compiled grains to custom grain modules #47372

Merged
merged 3 commits into from May 29, 2018

Conversation

gtmanfred
Copy link
Contributor

What does this PR do?

If a grains module function accepts a variable named grains then 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 grains

Tests written?

Yes

Commits signed with GPG?

Yes

@gtmanfred gtmanfred requested a review from a team as a code owner April 27, 2018 20:25
@ghost ghost self-requested a review April 27, 2018 20:25
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:
Copy link
Contributor

@isbm isbm Apr 28, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'cmon, Dani, use PyTest, let's drop this camel case finally! 😉 Just assert that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are still using Unittests, so I am going to stick to unittests asserts until that changes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo. "Passed in a core grains", I believe.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that is not correct.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Release should not be capitalized though. ;)

@gtmanfred
Copy link
Contributor Author

re-run py

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Release should not be capitalized though. ;)


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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

non-deterministic

@gtmanfred
Copy link
Contributor Author

re-run py

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

Successfully merging this pull request may close these issues.

Accessing Grains in Custom Grains
5 participants