Add ios_atomic_vlan_migration module#1310
Add ios_atomic_vlan_migration module#1310vishnusingh2700 wants to merge 5 commits intoansible-collections:mainfrom
Conversation
Added documentation and examples for the ios_atomic_vlan_migration module, including details on parameters and return values.
for more information, see https://pre-commit.ci
|
Hello @vishnusingh2700 , Appreciate your contribution, but for newer configuration specific modules we would accept only resouce modules and the pattern it supports with considerable states. Let us know if you need any help. |
|
Hello @KB-perByte, thank you for the feedback I completely understand. You are looking for a Resource Module pattern with support for states (merged, replaced, etc.) to align with the current cisco.ios collection standards. I am definitely willing to refactor this module to follow the Resource Module architecture. I will look into the existing resource modules for reference and update the PR accordingly. Thanks for pointing me in the right direction |
Implemented merged, deleted, and gathered states with get_config support.
for more information, see https://pre-commit.ci
|
Hi @KB-perByte, I have refactored the module to follow the Resource Module pattern. It now supports merged, replaced, overridden, deleted, gathered, rendered, and parsed states. I've also implemented get_config to fetch live EEM configurations for the gathered state. Please let me know if any further adjustments are needed. Thanks |
Description
Hi team,
I have added a new module ios_atomic_vlan_migration that allows for a seamless, atomic migration of Management IPs and Trunk allowed-vlan cleanup on Cisco IOS devices.
Key Features:
Uses Cisco EEM applets to execute configuration changes atomically, which prevents administrative lockouts during IP migration.
Handles VLAN 1 removal from trunks and sets a new Native VLAN (Blackhole) for enhanced security.
Includes logic for both Root Bridge and non-root switches.
Request for Feedback:
This is my first contribution to the Cisco collection. I would appreciate it if the maintainers could review the code and suggest improvements to make it more robust or "Ansible-native." Specifically, I'm open to better ways of handling the EEM timer or making the subnet mask more dynamic.
Looking forward to your suggestions to make this module even better for the community!