Closed miyuk closed 4 months ago
And this module couldn't use check_mode with member_path.
This module is delete interfaces in spite of using --check
option.
Maybe, because this modules changes member params at fos.do_member_operation
.
This function has been in used all fortios modules.
I think we shuld add check_mode options on FortiOSHandler.do_member_operation
Hi @miyuk ,
Thank you for raising this issue, your steps are trying to delete a non-exist interface, so it return 404 not found, but even I have created interfaces through CLI, Ansible still can't achieve delete function, I have reported it to the development team, there are some existing issues around check mode function, I have reported them. Thank you again for your debugging.
Thanks, Maxx
Hi, @MaxxLiu22
Thank you for your reply. about non-exist interface, Ansible module should commit to be absent status by idempotency
When member_state: absent
, I think 404 error is not expected behavior.
Thanks
Hi @miyuk
Thank you so much for your time! When deleting a non-existing object and receiving a 404 error in response, this behavior does align with Ansible's idempotence principle. Here's why:
Expected Outcome: If the object doesn't exist, the desired end state is already achieved (i.e., the object is not present). Subsequent attempts to delete the same non-existing object will still result in the same desired state – the object remains absent.
Consistent Behavior: Ansible's idempotence isn't just about successful operations; it's also about consistent behavior across runs. Even though a 404 error is returned when attempting to delete a non-existing object, this consistent behavior ensures that subsequent runs of the playbook will not introduce any changes.
No Side Effects: Since deleting a non-existing object and receiving a 404 error does not alter the system's state, there are no unintended side effects from running the task multiple times. This aligns with Ansible's goal of ensuring predictable and safe automation.
In summary, while receiving a 404 error when deleting a non-existing object might seem like an anomaly, it does align with Ansible's idempotence principle because it maintains the desired state and ensures consistent behavior across multiple playbook runs.
@JieX19 I understood that this behavior is correct action. Close this issue.
Overview
fortios_system_zone
cannnot be absent state that already deleted params.Environment
ansible: 2.13.3 fortinet.forios collection: 2.2.3 fortigate: 7.2.4
Reproduction steps
test
with no interfaces.port2
.Expected behavior
No error, and zone interface
port2
is absent (no changed)