Clarification on present state behavior

[jcsicard]

Is the intended behavior of the “present” state to only add/update parameters passed to the module and leave all other existing parameters untouched or are the parameters passed meant to be represent the complete “desired state” of the object, meaning that existing object parameters not passed to the module should be removed?

I expected the second but my actual results and reading of the code lead me to believe it’s the first...

[jmcgill298]

The modules are expected to behave in the former manner, which is standard Ansible behavior. For example, the apt module doesn't remove packages that weren't specified, and the file module doesn't delete attributes of an existing file that weren't specified.

[jcsicard]

Ok, I see.
What would be the recommended workflow to "reset" the complete state of an object(s) to a specific state? Case at hand being, we produce, automatically, a json/yaml file describing all the flows/objects required for en environment, which I then push to the Fortiamanger through the fortimanager-ansible modules. When I have an updated file, I diff it with the previous for deprecated objects which I then "remove" with "state: absent" calls. However, if the object is still present but has parameters added and/or removed (address_group with removed members for example), would the intended workflow to be to go through each object twice, once with state "present" and a second time with "param_absent" and a diff of all removed params ?

[jmcgill298]

Correct, the "param_absent" was built-in to allow removing entries from an object partially. You would need to retrieve what is currently there and diff against what you would like to be configured and then remove the extra configuration.

[jcsicard]

Right. I guess I'll have to deal with it playbook side at this time then.
Would you be open to adding a new state that combines "present" and "parm_absent" ("present_param_replace" state perhaps) in a single pass in order to configure a "complete and inclusive" desired state if I contributed such a PR? This would reduce playbook complexity/api back-and-forth/execution time required to update a whole config to a specific desired state...