OndrejHome
commented
1 year ago Hi Michael (@SoMoney ),
Thank you for using the modules and finding time to describe the issue that you see! The HANG behaviour sounds strange from what you describe and I wonder what it is causing. There are no timeouts inside of these modules so in case that some action takes longer than usual then module will wait for as long as the given ansible version allows (not sure from top of my head what that is, but remembering some older code where this can be counted even in hours ).
To have a better look:
- Would it be possible to share the task/playbook where the hang occurred ? (you can remove sensitive data and/or send it via email if not comfortable sharing it publicly)
- Could you please let me know some details about system on which this appeared?
- Distribution name+version where target is,
- ansible --version` from machine where playbook was run
- Which version of targetcli-modules have you used (latest
masterfrom GitHub or version from Ansible Galaxy)
It has been some time since I had a look at this code and I plan to check this further either during this week or this weekend when I get more information from you.
This module is much better than using shell commands like I'm doing currently.
This exactly was the main motivation when I created it :)
Thank you and I hope I will hear from you soon.
Hi Ondrej, also want to give a big thanks for the great work you put into this module. I notice there doesn't seem to be a safety measure when you run the play a second time on the same box, the play will just hang. Since I've never seen this HANG behavior on a module execution before, I had to register targetcli ls output and add when: "'iqn.20' not in targetcli_ls.stdout"
I'm testing a role where I can change target and initiator passwords regularly. Having some logic where it doesn't hang on duplicate targets and only updates what's different would be nice for ansible newbs like me. This module is much better than using shell commands like I'm doing currently.