Hi Adrian
- Regarding the barrier between init and configure, this is correctly
implemented its just that something failed and we didn't know.
- It's going to be hard to define a useful timeout for whirr and all
other jclouds client projects for all script executions, if you are doings
other things maybe a smaller timeout would be better.
So my suggestion is:
- Change things so that on can be notified on a script timeout (by
exception or otherwise). Better yet allow chose a policy (like a
runscriptoption) for notify/fail silently and allow to set timeouts for
particular scripts.
- Whirr has to deal with large cluster where there might be slower
nodes and should set an adequate timeout for this context (like 20 min).
The ideal solution for whirr IMHO would be:
- Start N nodes
- Init N nodes. If some fail there is still time to add new ones before
configure.
- Configure all nodes.
just my 0.02$
-david
On Oct 13, 2011, at 6:52 PM, Adrian Cole wrote:
> Hi, David.
>
> It is true that jclouds chooses not to enforce script timeout right now. We
> can still change this before 1.2.0, as it is a valid concern. Note that in
> doing so, we'll need the timeout property set to a reasonably high value,
> but not infinite.
>
> Would you like this to throw an exception on timeout?
> -A
>
> On Thu, Oct 13, 2011 at 4:45 PM, David Alves <[email protected]> wrote:
>
>> Hi All
>>
>> I lost track of the discussion….
>> What was the final status of the script timeout problems (I mean
>> when the init script takes longer than 10 mins the configure scripts are
>> executed as if all went well).
>> Is this expected? should a jira be open (or has it)?
>> I just ran into this problem on one of my tests…
>> … at the very least configure phase should not be executed on nodes
>> that have not finished init'ing right?
>>
>> -david
