Hi Brad, Thanks for the reply.
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 :) Thanks again, Andy. Sent from a teeny tiny keyboard, so please excuse typos > On 3 Oct 2018, at 13:30, Brad Van Orden <[email protected]> wrote: > > Hi Andy, > > 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? > > Regards, > > Brad > >> On Wednesday, October 3, 2018 at 2:31:18 AM UTC-4, Andy Lemin wrote: >> Morning Brad, >> >> 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. >> >> Cheers, Andy. >> >> >>> On 2 Oct 2018, at 17:11, Brad Van Orden <[email protected]> wrote: >>> >>> Can you upgrade your device to IOS 15.6 or greater? That might be easier >>> than trying to find a work-around? >>> >>>> On Tuesday, October 2, 2018 at 12:02:24 PM UTC-4, [email protected] >>>> wrote: >>>> Hi, >>>> >>>> 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 >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "Ansible Project" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/ansible-project/sAgM6EvjLWs/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> To post to this group, send email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/ansible-project/44369ab9-c0d9-43ea-841b-fa72157d5893%40googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to a topic in the Google > Groups "Ansible Project" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/ansible-project/sAgM6EvjLWs/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/f9dd06f5-0828-4ffe-9b6f-7362f20fb541%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/3F0181D2-EAA6-4EBF-83A4-DA45E46FDA8D%40gmail.com. For more options, visit https://groups.google.com/d/optout.
