Ненавижу, но люблю 🤯

В чем история, познакомился я тут как-то с модулем win_package, чтобы удалить виндовый пакетик по его GUID... и лучше бы я этого не делал.

Все делал довольно базово, коннект у меня шел по winrm к доменному хосту по порту 5985:

ansible_connection: winrm
ansible_winrm_transport: ntlm

Казалось бы что тут может пойти не так, а вот что:

[WARNING]: Failed to cleanup running WinRM command, resources might still be in use on the target server
...'Connection aborted.', error(104, 'Connection reset by peer')

Хм... окей, пошли смотреть в winrm.py, что это за warning интересный... обнаруживается вот это:

        except requests.exceptions.Timeout as exc:
            raise AnsibleConnectionFailure('winrm connection error: %s' % to_native(exc))
        finally:
            if command_id:
                # Due to a bug in how pywinrm works with message encryption we
                # ignore a 400 error which can occur when a task timeout is
                # set and the code tries to clean up the command. This happens
                # as the cleanup msg is sent over a new socket but still uses
                # the already encrypted payload bound to the other socket
                # causing the server to reply with 400 Bad Request.
                try:
                    self.protocol.cleanup_command(self.shell_id, command_id)
                except WinRMTransportError as e:
                    if e.code != 400:
                        raise

                    display.warning("Failed to cleanup running WinRM command, resources might still be in use on the target server")

Ладно подумал я... возможно проблема в транспорте и типе подключения, давай поменяет на CredSSP

ansible_connection: psrp
ansible_winrm_transport: credssp

И тут такая же история... но уже с другой ошибкой, которая так же тянется из winrm.py:

  msg: 'Unexpected failure during module execution: Received a WSManFault message. (Code: 995, Machine: xxxxx, Reason: The I/O operation has been aborted because of either a thread exit or an application request.)'
  stdout: ''

Думаю надо еще потыкаться и попробовать удалить пакетик не через модуль win_package, а напрямую через shell модуль, спойлер, наткнулся я на такие же ошибки, но обнаружил любопытный моментик:

[WARNING]: Failure cleaning temp path 'C:\Users\Administrator\AppData\Local\Temp\ansible-moduletmp-XXXXXXXXXXXXXXXXXXXXX': Win32Exception NtSetInformationFile() failed 0x00000001: Incorrect function
changed: [XXXXXXXXXX] => changed=true 
...
...
  rc: 0
  reboot_required: false

То есть когда модуль не может очистить временный файлик, тогда удаление пакета проходит успешно.
Океееей... я пошел гуглить и разбираться почему такое происходит и оказалось, что после исполнения удаления пакетика с помощью транспорта winrm он уходит в ребут и рвет соединение 🙃

ВСЕ, с этим ничего не сделаешь, так работает winrm

Какие остались варианты...
1) Обработка ошибки - обрабатывать конкретную ошибку не стал... ибо увидел, что у неё есть определенная вариативность и страшно представить, сколько я еще потенциальных проблем из-за транспорта мог не поймать
2) ignore_errors: true - ну это совсем плохой вариант
3) block / rescue - а вот это то что нужно, по сути после ошибки мы производим повторное выполнение таски и восстанавливаем winrm подключение

Вот такие пироги...