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 <brad.vanor...@gmail.com> 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 <brad.v...@gmail.com> 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, andrew...@gmail.com 
>>>> 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 
>>> ansible-proje...@googlegroups.com.
>>> To post to this group, send email to ansible...@googlegroups.com.
>>> 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 
> ansible-project+unsubscr...@googlegroups.com.
> To post to this group, send email to ansible-project@googlegroups.com.
> 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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
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.

Reply via email to