You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@vcl.apache.org by Andy Kurth <an...@ncsu.edu> on 2010/02/03 15:38:42 UTC

Re: Move response checking from provisioning module to OS module

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_kurth@ncsu.edu
919.513.4090

Re: Move response checking from provisioning module to OS module

Posted by Brian Bouterse <bm...@gmail.com>.
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 <an...@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_kurth@ncsu.edu
> 919.513.4090
>



-- 
Brian Bouterse
ITng Services