panos_device_group implements changes when state: gathered is set
torch183 opened this issue ยท 2 comments
Describe the bug
When running a task with panos_device_group
module where both state is gathered and name is defined, a change was implemented on the panorama device.
Expected behavior
I realize that I should have used gathered_filter to specify which device_group to get info about, but I would expect ansible to either throw an error if state: gathered
and name: mygroup
are incompatible or return some sort of info about either no groups or all groups.
I initially gave the wrong name for the group (Mygroup instead of mygroup), and the task failed with
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Object 'Mygroup' not found"}
. IF config write is supposed to be possible with state: gathered
set, I would expect ansible to create a new device group with the new name instead of throwing an error.
Current behavior
The device group specified by name
was moved to the top of the tree structure (ie. out from its current parent)
Possible solution
Let state: gathered
block any proposed changes, a la check_mode
Steps to reproduce
- Create a parent device group and a child device group below the parent.
- Create a task as such:
- name: Get devicegroups
panos_device_group:
provider: "{{ provider }}"
state: gathered
name: "child_group"
Verify that the child group was moved away from its parent
Context
I at first did not notice that the device group was moved, so the next time somebody committed and pushed changes to Panorama, the device group in question lost most of its rules, which was unfortunate.
I compared the reported behavior with how the panos_address_object module works, and I was not able to change any objects as long as state: gathered
was set.
Your Environment
- Panorama: 10.1.9-h1
- Collection: paloaltonetworks.panos 2.17.2
- Python: 3.10.6
- Ansible: core 2.12.0
- PAN-OS Python Library & version ( pandevice 0.14.0, pan-os-python 1.8.0, pan-python 0.17.0):
๐ Thanks for opening your first issue here! Welcome to the community!
๐ This issue has been resolved in version 2.17.5 ๐
The release is available on Ansible Galaxy and GitHub release
Posted by semantic-release bot