I am interested in adding another feature to the core module so when using the “dry run” check mode and diff mode it doesn’t just skip, and can display a message of what would occur (if using creates/removes/only_if/etc).
I was thinking of adding another parameter like diff_msg=“Run program x” to the command module and having that display for a diff message. It’d actually be nice to be able to output the message for any module, so maybe it belongs somewhere else.?.
I know we could do debugging and I think I saw a parameter to add to add a debug message, but I’d rather not clutter up end-user output with debugging mode and looking for something for the diff. I’m running in non-production read-write and production read-only environments, so the diff mode becomes important to know what is changing.
Maybe as an alternate/additional option, any thoughts on creating a patch file for all differences so it could be run by another third party. They won’t have ansible nor can we control that so the ability to create a usable simple shell script/and or patch file(s) might be helpful.
Any thoughts on that or advice on implementing it would be appreciated.
Thanks,
I would not want it to report what programs it would have changed, but rather what attributes it would have changed or DID change.
This is really a larger question though independent of check mode.
Since the modules report the end state, what this idea is really about reporting the initial state of the system and being able to track it over time.
We’ve called this concept “query” modules in the past and I think it’s definitely something we want to do to track how inventory/systems change over time.
Yeah, agreed, I would want to see attributes changed.
I think the idea was for an action, you really don’t know what it is changing since you’re running arbitrary commands, so adding a user-defined diff message would be up to the user to say what is running for their diff (replace with variables), much in the same way that they’re defining the command that gets run. While it’s hard to determine beginning state from an arbitrary command, we can determine state based on the things we’re looking for such as the creates, removes, only_if, etc, and log those before and after states… maybe that’s a better way to go actually… I’ll do some more thinking on that.
The other issue was things like file module not really reporting true differences… for example, comparing a file of type link in dry run check mode just skips instead of stating a diff of the symbolic link locations it’s changing from and to. For my use case, even knowing in check mode that it is running a sym link because they don’t match would be helpful, instead of just saying it’s skipping it.
I’ll do some searching on the “query” modules you spoke of. Sounds like it might be of help to me. Thanks for that suggestion.
Quick PSA:
only_if is a legacy construct, “when” is the preferred way of doing things in 1.2
However I should also point out that “when” is evaluated “server” side.
The --diff mode is not there to show changes in resource state, btw, but rather changes in file contents.
Basically the query module needs to be a whole namespace of modules for inventorying basic things.
I know there are things I want to use this for, but it would be also really cool to have a quick port of Func-inventory using them, because it was pretty awesome.
I can see it also tracking the ‘setup’ module as part of this.
https://fedorahosted.org/func/wiki/FuncInventory
https://github.com/mpdehaan/func/blob/master/func/overlord/inventory.py
Long story short, it’s a cool way of using git to generate RSS feeds for how all of your systems change over time, in a very small amount of code.
It’s onmy radar, I’m not sure it’s something I want to see happen for 1.3 or 1.4 though. Thinking about it.
One thing I’d point out is that a “query” only module isn’t really beneficial in my use case where I just want to know what changed/would change. For one, I don’t want to have to rewrite for read-write systems vs read-only systems. Anotherwords, why write one file module to check indempotent state, and have to use another module to make a change on systems it is able. I’m not understanding why a system in a check/diff mode wouldn’t want to fully tell us what is different and why, even if it is the resource itself and not contents… and in a way, for a symbolic link, the link itself is the contents.
So If I have development systems that I can run actual changes on, great, it runs them… but then I need a way to summarize all differences so they can be given to a third party/reviewed for compliance (PCI/HIPAA/etc) and implemented on production systems I don’t have read-write access to and would love to log in something like Nexus as change artifacts. Maybe Ansible isn’t meant to “diff the entire systems” but rather actually control them only, so maybe I’m stretching it to things it really wasn’t intended for.
In any case, I believe it’d be a nice-to-have, to allow it to either make the change, or on systems it cannot, to show what it would need to do to bring the system into check. I’m not sure why wouldn’t want to show this information for diffs. While I like the idea to be able to query state and the information you provided, I’m not so sure this is a good way to do what I am looking for, which is to show change differences of items that Ansible would change, whether they be state or content. Maybe then, a separate flag of --diffstate if they are considered two separate things…
Just my two cents. 
So my needs are a bit different in what I want to do.
Stuff like “show all users”, and be able to track changes over time is different than seeing how a given user was specifically modified.
So yes, this is ENTIRELY after the compliance feature, with the query module idea.
Just reporting what attribute it would change doesn’t quite get us there.
In any event, I do not think this should be a new flag, but rather a convention in the return of the module.
–diff is a flag because it injects additional and expensive behavior of analyzing file contents and returning them, etc, but the idea of a module return reporting the full state of the object and a seperate list of “changes” is reasonable.
In particular, see how the “file” module returns most of the attributes of the file when it returns. I think that is (in general) what we should be going for, but what it returns is the final result.
If it also returned a list of changed fields, that might be pretty close, i.e.
{
mode: 644,
changed: [ ‘mode’, ‘context’ ]
…
}
??
I think that different convention of the return of the module you explained would do well for my needs assuming all of the information is contained therein. That would be excellent.
Let me know of anything you’d like me to do to make that happen. I’d be happy to help.
I think we should start with implementing this for the service, user, file, and group modules – which gets the majority of things (copy and template use file internally)
And then other modules can be improved from there.
If this is something you would like to work on that would be great – just be sure to test all of the various operating systems involved as the user and service implementations can get tricky.
I am thinking the easiest way to it might be if the module common code had a “changes” list set up in the constructor and there was a module.add_changed_field(‘field’) method to minimize
the heavy lifting, and if any changes are reported (the list is not of zero length) it would be automatically returned when exit_json was called.
Does that sort of make sense?
I want to minimize the amount of heavy lifting and changes needed to add this to each module.