Do the eos network modules (2.1) accurately return the ‘changed’ status in check_mode? In reading the code, it appears as if the value of ‘changed’ has more to do with providing a valid config to push. The result of this would be that, assuming valid configs, --check would tell me every time that something would have changed, even when it would not have.
The only way I can think to do it would be to copy the config from the router and try to merge the supplied commands and then see if anything changed (action_plugin).
However, (and this might require an EOS-API update), it would be great if I could pass the config commands to the switch via eosapi and then the api on the switch could simulate the merge. Juniper has this built into their os (standard config changes via cli only modify a candidate config that you can show and diff before deciding to commit or abort), so they didn’t have to do anything special to return a proper ‘changed’ or ‘diff’ to ansible.
If the EOS modules are not planning to support this, then I would argue that they should set ‘supports_check_mode’ to false so that it can be skipped instead of always telling me something is changing.
If you are referencing the new modules eos_config and eos_template then changed status is set to true if a change is required on the node. In the context of the module, it means that one or more config lines need to be pushed to the device to bring the running config into alignment with the desired set of config lines.
To your point it doesn’t represent the validity of the command but then again thats not the design goal of the module so I assert the module is doing things the correct way.
even in check_mode? I’ll have to try it out when 2.1 comes out.
Is there a way to send the diff back to ansible when --diff is used? I didn’t see any ‘before’, ‘after’, or ‘prepared’ in the module, but I may have missed it.
cool, thanks. I assume it reports no changes if “hostname foo” was already in the config.
I am excited to start using these. Is the --diff stored in “updates” or is that just the commands that were sent (regardless of if they were already part of the config or not)?
Thats right … I updated the gist to show the output if you remove the --check and allow the module to push the change. You will see in the second run that updates: is returned with changed: false in the json return.