I just want to quickly check a finding with the community, something which should be so trivial it must be me
I have found that it is not possible to remove Cisco users from IOS 12.x using the Ansible module ios_user:
This is becuase IOS 12.x doesnt support âshow running-config | section usernameâ which the module tries to run.
Ok, thats fair enough. So Iâll have to write the logic using ios_config: module insteadâŚ
But ios_config: still does not seem to support âprompt:â and âanswer:â
Catch 22! As IOS prompts user removal with;
âThis operation will remove all username related configurations with same name.Do you want to continue? [confirm]â
Thankfully, and only by dump luck, IOS 12 does not give this prompt, so ios_config: does work⌠in this one case⌠PhewâŚ
But this to me seems like another exmaple of how much we need ios_config: to support âprompt:â and âanswer:â as Cisco IOS plays so poorly with Ansible compared to other vendors becuase of the Cisco CLI.
Thanks for your thoughts.
Kind regards, Andy Lemin
I know in an ideal world, in a lab or a proof of concept, upgrading every device would be the obvious and easiest thing to do.
But sadly when dealing with large brown-field networks. Their are often many technical and operational restrictions preventing an IOS upgrade.
In this case, deploying key network automation functions is the very thing that will allow us to resolve some design factors, which in turn will ease upgrades to 15!
So catch 22, we have to support IOS 12, to get to a place where we can realistically start upgrading all the legacy edge devices to IOS 15.
Understandable. Can you accomplish your task using shell or command module? Maybe use the expect module to switch to enable mode, then shell or command from there to achieve your task?
Good reminder about the âshellâ methodâŚ
However I am trying to be strict about code quality and where complex logic resides.
For example Ansible is a nice clean framework, for automating complex but repeatable actions/logic. The âshellâ method however would be breaking this rule by bringing complexity into the playbook.
As such I think I would prefer to write a custom module and keep the playbooks elegant and clean so itâs readable and usable by NOC staff etc. That requires extra work, but would still be preferred as a last resort.
I am actually new to Cisco automation with Ansible, my experience has been with JunOS which has been a dream compared, due to the JunOS CLI structure being a data model in itself and so being able to do most, if not all within jinja2 and lookups.
As a result I came to the conclusion that ios_command is for running show commands at âexecâ mode. And ios_config is for running configuration commands within the âconfigure terminalâ level.
So are you saying itâs possible to use the expect module with âios_commandâ, to get ios_command to run stuff at the configure terminal level? Any examples you know of.
If yes that sounds like the cleanest short term workaround to just run a config command which requires prompt handling
No, darn it. I forgot those modules expect python on the target. So, expect, command, shell, etc wonât work. I think what you want to do is something like (I donât have any way to test this at the moment):
Ahhh, yeaâŚ
The provider is network_cli, so paramilkoâŚ
I miss NETCONF
Youâve just spun another ios_* module assumption I had around
I was under the impression that each â- name:â definition was bounded with ios_. And so a subsequent â- name:â stanzas would go back to their root again, and thus you couldnât chain commands to elevate the CLI levels like your example.
Let me test. Youâve given me lots of ideas on how I can do this cleanly, as I want the IOS 12 workarounds to be the exceptionsâŚ
