Indeed, thats what I had in mind. Keep trying to ssh with a suitable timeout.
Thanks!
Regards,
Girish
On 30-Sep-2013, at 2:40 PM, Jayapal Reddy Uradi
wrote:
> Hi Girish,
>
> While selecting the delay I suggest the following.
>
> In general check the time taken for the router boot up.
> Ta
Hi Girish,
While selecting the delay I suggest the following.
In general check the time taken for the router boot up.
Take the max interval as 10 times of boot up time.
Repeat the ssh for each boot up interval.
Thanks,
Jayapal
On 30-Sep-2013, at 1:38 PM, Girish Shilamkar
wrote:
> Marcus,
Marcus,
I guess it no longer applies to even KVM . I have seen the router in running
state and yet fails to accept
ssh connection.
Santhosh,
Adding random delay is what I am trying to avoid or at least minimise. Thanks
for the suggestions.
Regards,
Girish
On 30-Sep-2013, at 12:18 PM, Marcus
In the past, with KVM, the agent doesn't show the router as running until
it can ssh to it. You can watch the agent poll if it is debug logging. Does
this issue not apply to KVM, or is it a regression?
On Sep 29, 2013 11:38 PM, "Girish Shilamkar" wrote:
> Hello,
>
> Egress rules tests rely on acc
Girish,
cloudstack shows router status as 'running' before the router booting
completed. The router is accessible when the cloud-early-config starts the sshd
in booting.
+1 on santosh suggestion.
Thanks,
Jayapal
On 30-Sep-2013, at 11:25 AM, Santhosh Edukulla
wrote:
> Girish,
>
> 1. Usin
Girish,
1. Using timeout will make it to wait for that many units always and again it
may not be fool proof, we may succeed to find ssh daemon on remote machine is
up and running and with this, we again run it few more times to check again if
it is not running, so its not much predictable.
I
