Food for thought (from chat with Andrei) is that we can make a new idiomatic runScript call in jclouds
like Future<ExecResponse> runScriptOnNode(id, statement); in this case, we can borrow Future semantics for things like get() cancel() etc. That way you can manage your own timeouts. WDYT? -A On Thu, Oct 13, 2011 at 4:51 PM, Andrei Savu <[email protected]> wrote: > We should open a Jira and enforce the barrier as much as possible ideally > through jclouds. > > -- Andrei Savu > > On Fri, Oct 14, 2011 at 12:45 AM, 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 >
