Andy, 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 integration project.
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. Best, Brian 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 > > > 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. >> >> Thanks, >> Andy >> >> >> 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 > andy_ku...@ncsu.edu > 919.513.4090 > -- Brian Bouterse ITng Services
