I discovered that the persistence command_timeout variable was added in 
Ansible 2.7 (which I am not using). So I will just set them as global 
variables for now. Thanks again. 

On Tuesday, October 2, 2018 at 3:24:25 PM UTC-4, Dow Bennett wrote:
>
> I had no luck with asynchronous actions or the wait_for_connection. 
> However, I did find if I set the persistent connect_timeout and 
> command_timeout in ansible.cfg to a value high enough for the command to 
> complete that it works! However, I would prefer if the ansible.cfg file 
> didn't have these set permanently. I know there is a way to set them in the 
> playbook.. but I haven't figured it out yet. I'm sure its basic but like I 
> said I am new to ansible. Any advice?
>
> Thanks for the help!
>
> On Tuesday, October 2, 2018 at 12:59:30 PM UTC-4, Brad Van Orden wrote:
>
>> Maybe do something like find in: reboot without failing ansible 
>> <https://www.jeffgeerling.com/blog/2018/reboot-and-wait-reboot-complete-ansible-playbook>
>>  ?  
>> Would that work?
>>
>> On Monday, October 1, 2018 at 2:12:15 PM UTC-4, Dow Bennett wrote:
>>>
>>> Hello! 
>>>
>>> I am a noob in Ansible so please forgive me. I am trying to upgrade an 
>>> OS9 switch using the dellos9_command module (there is a method to upgrade 
>>> OS10 via Roles but not OS9).
>>>
>>> playbook:
>>> ---
>>> - hosts: switch1
>>>   connection: network_cli
>>>   gather_facts: no
>>>   tasks:
>>>     - name: "Dell EMC OS9 S4048 Upgrade"
>>>       dellos9_command:
>>>         commands:
>>>           - "upgrade system 
>>> scp://user:[email protected]//home/user/FTOS-SK-9.13.0.3P1.bin a:"
>>>         interval: 500
>>>         retries: 1
>>>         wait_for:
>>>           - result contains successfully
>>>
>>> The playbook returns (after the 500 second interval):
>>> FAILED! => {"changed": false, "failed_conditions": ["result contains 
>>> successfully"], "msg": "One or more conditional statements have not been 
>>> satisfied"}
>>>
>>> On the switch, I can see the connection being made and then terminate 
>>> and show that the upgrade failed. 
>>> Oct 1 13:59:11.256 EDT: %STKUNIT1-M:CP %SEC-5-LOGIN_SUCCESS: Login 
>>> successful for user user on line vty1 ( x.x.x.x )
>>> Oct 1 13:59:11.398 EDT: %STKUNIT1-M:CP %SEC-5-CONCURRENT_LOGIN: User 
>>> user has 2 concurrent logins
>>> Oct 1 13:59:11.989 EDT: %STKUNIT1-M:CP %SEC-5-SSH_USAGE: Using SCP-SSH 
>>> v2 (FIPS Disabled)
>>> Oct 1 13:59:13.721 EDT: %STKUNIT1-M:CP %CRYPTO-5-FIPS_SELF_TEST_PASSED: 
>>> [scp] FIPS crypto module self-test passed
>>> Oct 1 13:59:21.861 EDT: %STKUNIT1-M:CP %SEC-5-LOGOUT: Exec session is 
>>> terminated for user user on line vty1 ( x.x.x.x ) (Reason : Admin Reset)
>>> Oct 1 13:59:21.981 EDT: %STKUNIT1-M:CP %DOWNLOAD-6-UPGRADE: Upgrade 
>>> failed
>>>
>>>
>>> The command works manually. But what I think is happening is that the 
>>> switch responds with periodic "!" (I assume as a type of progress bar) 
>>> until it is "Installed successfully" and Ansible is taking the "!" as the 
>>> response and terminates the session. Is there some way to force the session 
>>> to stay open for a set period? I don't really need to verify the result.
>>>
>>> Thank you,
>>> Dow Bennett
>>>
>>

-- 
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/ff759158-cd78-4c7c-b308-164e252f0683%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to