test-kitchen / winrm-transport

WinRM transport logic for re-using remote shells and uploading files
Other
8 stars 9 forks source link

Regarding winrm connection timeout #13

Open puneetloya opened 9 years ago

puneetloya commented 9 years ago

bundle exec kitchen exec windows_host -c "bat_file"

I am running a batch file, which must run for about an hour. Many times the winrm connection is timing out by 21 mins. I am not sure if the figure is important.

The windows system winrm config has timeout of 1800000. (half an hour). I am not sure where should I set timeout so that the tests can run correctly

fnichol commented 9 years ago

That is a good point, would you see this working as a configurable attribute?

puneetloya commented 9 years ago

I did not get your point. Please explain. I tried to configure it a lot of ways, but this issue keeps popping, and its not consistent. You can find similar problem explained here https://github.com/WinRb/WinRM/issues/146. Can you speculate any reason on why is this happening?

fnichol commented 9 years ago

At the moment we can't change this timeout, but I'm convinced that we need to have that ability.

Have you seen this timeout be an issue while running kitchen converge?

puneetloya commented 9 years ago

No, the timeout occurs during kitchen exec.

kitchen exec windows_system -c "C:\run_tests.bat"

Kitchen converge is working perfectly fine.

carpnick commented 8 years ago

I think the next step here is to wait for winrm-transport and winrm-fs to merge.

Once complete, we rethink the configuration of WinRM sessions, and the specific location of that code. I think alot of the WinRM session code would move into the more generic Gem, that kitchen would leverage. This would allow options to be exposed at the transport layer and within kitchen. We could have different timeouts for different use cases. Like Kitchen could have timeouts for convergence that are much different than file copy, etc. Also in this case kitchen exec could potentially map to a more generic execute timeout, which is different than the converge timeout.

Potential:

transport:
  winrm_common_config:
     #Global options if there are any - think SSL etc.
  winrm_converge_config:
     #WinRM Specific Config Options - including Timeouts
  winrm_filesystem_config:
     #WinRM Specific Config for file transfer etc          
  winrm_execute_config:
     #WinRM Specific Config for executing random commands

Each configuration section above could map to a different static session method. Then you just use the correct method for the different use cases. Now the user would have ultimate control of tuning for each of the different use cases. The different config options would probably live in kitchen repo as this gem is suppose to disappear.

My 2 cents.