-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Inconsistent state return when test=True #40208
Comments
@whiteinge and @terminalmage do you have any thoughts on this? Thanks, |
Your sleuthing is commendable. This is an in-progress feature addition and I don't think we ever documented or explained it. The history behind this is
To my knowledge, we haven't yet added Does that answer your questions? I'm interested to hear your thoughts. |
Thanks much for the quick response. It appears that I was on the right track with my assumptions. Below are my thoughts as a new contributor to saltstack. IMHO (with which $2 will get you a coffee), the pchanges enhancement is a great idea that should be advanced more aggressively. My suggestion would be:
From my quick survey, it's really only highstate that directly references/calls out |
Move default_ret and loaded_ret into salt.utils.napalm, and update the dictionary returned based on discussions in saltstack#40208. Diffs are copied into comment if this is a dry-run, and changes are only set if an actual change is made on the device.
All great suggestions. I agree. I'll point the Core team to this conversation. Some of these are more work than others but all are things we should get to eventually. |
Having also observed this issue, it would be good to see it fixed. comment = 'Certificate {0} '.format(name)
if not __salt__['acme.has'](name):
comment += 'would have been obtained'
elif __salt__['acme.needs_renewal'](name, window):
comment += 'would have been renewed'
else:
comment += 'would not have been touched'
ret['comment'] = comment
return ret Would become something like pchanges = 'Certificate {0} '.format(name)
if not __salt__['acme.has'](name):
pchanges += 'would have been obtained'
elif __salt__['acme.needs_renewal'](name, window):
pchanges += 'would have been renewed'
else:
pchanges = None
ret['pchanges'] = pchanges
return ret (The acme.cert block has the nasty issue at the moment, where it makes a comment regardless of what's happening, hence it "always" appears to change when test=True) |
@timwsuqld good addition. Below is a quick checklist. (We should get these in the docs.)
|
Hi - thanks all for the inputs, that really helps me clarify and I've bookmarked this issue and revisit it and go through the checklist when I develop a new state, just to make sure I'm doing it properly. Regarding:
Would |
Yes, that has been the pattern even for failures. However the use-case is plenty valid. This same question just arose in #42553. |
Thanks for pointing that out @whiteinge -- having |
Overall I really like |
Sorry to bring this up after a while of silence. I've just submitted the PR #44603 which is a quick fix for the state always returning changes on @timwsuqld not sure if you got anywhere with working on Feel free to undo what I've done in any of your work to correct the issue in a nicer way. |
Previously, the acme.cert state would return that a change was pending during a test run even in the case that the certificate would not have been touched. Changed the return value in this case so that it is not thought to require a change. This is reported in saltstack#40208 [0] and is also referenced in saltstack#42763 [1]. The issue saltstack#40208 looks to go on to recommend further changes beyond the scope of this 'quick fix'. [0] saltstack#40208 (comment) [1] saltstack#42763 (comment)
2019.2 release lacks diff output when running |
@sidharrell I'm guessing that wasn't intentionally removed? |
Yes I also experience the same and the issue is this commit : in file.py they stopped to populate As a test I reverted that commit, and now I see the changes while |
It's related to this #51932 |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue. |
Was this issue ever resolved? |
While working on a change to fix up the return of some network configuration diffs when test=True or when no changes are made, I ran into a lot of inconsistencies in the code base and documentation regarding the correct way to return potential changes when testing.
From the addition of
ret['pchanges']
in cbd9590, it appears that there was a desire to differentiate when changes are ACTUALLY made by salt, and when changes WOULD be made, but weren't because we were testing. This is kind of reflected in the highstate outputter, as the summary counts the # of states that haveret['changes']
not empty as changed and # of states withret['result'] == None
as unchanged. This can still be seen as states such as file.directory will useret['pchanges']
to populate information inret['comments']
to indicate what would happen iftest == False
Currently, this results in confusing output, as modules like file.managed will set
ret['changes']['diff''] = ret['pchanges']['diff']
, resulting in the summary stating that it was both changed and unchanged at the same time.I think this was due to some regressions where the file diffs were getting lost, as the highstate outputter does not show
ret['pchanges']
at all. Perhaps we should update the highstate outputter to displayret['pchanges']
instead ofret['changes']
whenret['result'] == None
, and update documentation to indicate thatret['changes']
should only be populated when a change was actually made.I'd hope that this prompts a discussion to create something definitive on how states return and display potential data. I apologize if this has already been brought up -- my search for issues didn't turn up anything directly relevant.
The text was updated successfully, but these errors were encountered: