If you don't mind, could you do the copy/paste job. I have no way of
testing it either without re-setting up our testing infrastructure for that
Also, a general thanks for applying updates to the esxthin.pm code so that
is stays relevant with the VCL project. In the future as these updates need
to be applied I will help out where I can.
On Wed, Feb 3, 2010 at 9:38 AM, Andy Kurth <andy_ku...@ncsu.edu> wrote:
> This is an update on VCL-291. I have made the changes to all of the
> relevant files except for esxthin.pm and committed them. I didn't want to
> touch esxthin.pm in case Brian is working on it. The changes are
> currently being tested/used in NCSU's production implementation and I have
> not seen any issues so far. Having the OS modules check for SSH after an
> image is loaded is working better. This is done by
> OS.pm::wait_for_response(). Version_6.pm also implements its own
> wait_for_response() which accounts for longer times needed by Vista/2008.
> The subroutine suggested by Sean to perform multiple attempts of running
> code has been implemented as Module.pm::code_loop_timeout(). It takes
> arguments of: a code reference, arguments to be passed to the code, message
> string to be displayed in the log output, total seconds to attempt to run
> the code, seconds between attempts. It runs the code reference until it
> returns true or the timeout is reached. If the code reference returns
> false, it waits the specified number of seconds and tries again. This is
> used by wait_for_ssh(), wait_for_ping(), and wait_for_no_ping() in OS.pm.
> Brian - the changes for esxthin.pm are minor. In load(), remove the SSH
> checking section and replace it with a call to $os->post_load(). This code
> can be copied from one of the other provisioning modules. I can go ahead
> and do this but I don't have a way of testing it.
> Andy Kurth wrote:
>> I think having the provisioning modules call post_load() will allow for
>> the greatest flexibility. Since it shouldn't be much of an imposition and
>> matches how capture() works, I'll work on coding the following changes:
>> -call to $os->post_load() removed from new.pm
>> -call to $os->post_load() added to each provisioning module's load() sub
>> -code removed in provisioning modules which waits for computer to respond
>> -code which waits for the computer to respond added to each OS module's
>> post_load() sub
>> After thinking about it, I don't see the need for new.pm to do any
>> looping. It should call the provisioning module's load() sub once and check
>> the return value. The provisioning modules can implement repeated attempts
>> as necessary within the load() sub.
>> It is useful the $os->post_load() to know if it's being run for the first
>> time or a repeat attempt. It could increase its timeouts if it's a repeated
>> attempt. I will have the provisioning modules pass it the attempt number.
>> A looping subroutine would be useful in many cases. Good idea. It may be
>> better to create such a sub in Module.pm so that all types of modules have
>> access to it. I'm thinking of creating a sub which you pass a code
>> reference and some timeout parameters. It attempts to run the code until it
>> returns true up until the timeout is reached.
>> Sean Dilda wrote:
>>> I don't think having $provisioning->load() call $os->post_load() would be
>>> such an imposition. However, if you want to have multiple attempts at
>>> $os->post_load() as was mentioned in an earlier email, it'd be nice to have
>>> a function defined in the OS module to do that looping.
>>> I haven't used the xCAT module. What does makesshgkh do?
> Andy Kurth
> Virtual Computing Lab
> Office of Information Technology
> North Carolina State University