Hello Toks,
Good questions, answered inline...
Toks Adeshiyan wrote:
Hi all,
I have a couple of questions relating to the provisioning/deprovisioning
processes in VCL...
(1) I would like to understand better why the provisioning modules
update the IP address of the resource being provisioned during the load
process (via the getdynamicipaddress function). It appears that VCL
will make the same call sometime after the load process completes. Does
this behavior change depending on the state in which the request was made?
You are correct in that there is some duplication of this call. It's getting
called by both the provisioning modules' load() subroutines and
new.pm::reserve_computer().
The getdynamicaddress() subroutine's purpose is to retrieve the current public
IP address being used on a computer. The computer table's IPaddress column is
then updated in the database. This needs to be done if the computer is using
dynamic DHCP because it may receive a different IP address after it is reloaded.
The computer.IPaddress column is used to present the connection information to
the user. It needs to be updated or else the user may be directed to connect to
the wrong IP address.
The request state does matter. The call from $provisioner::load() will happen
when a request in state new or reload is processed and the computer needs to
be reloaded. (Note: the computer may not need to be reloaded if it already has
the correct image loaded)
The call from new.pm::reserve_computer() will only happen if the request state
is new. This means if a user makes a reservation for an image that isn't
loaded, getdynamicaddress() is called twice. If a user makes a reservation for
an image that is already loaded, getdynamicaddress() is called once from
new.pm::reserve_computer().
If a reload request is processed (request.state = reload), getdynamicaddress()
is called once from $provisioner::load().
Your question brings up a point regarding the ongoing OS and provisioning engine
modularization work. First off, the getdynamicaddress() subroutine in utils.pm
should be phased out and replaced by subs in the OS modules.
I'm not sure if it needs to be called in the reserve phase but it isn't hurting
anything except for increasing wait times a little bit. Is there any reason why
getdynamicaddress() needs to be called during reserve if it's always called
after load?
I would prefer to remove the calls from all of the provisioning modules and move
it up to new.pm::load(). This way, provisioning module implementations don't
need to worry about calling it and I also don't like the idea of provisioning
modules setting anything in the computer table. Any changes to the computer
table and most others should be handled by the state modules (new.pm, image.pm,
...) or vcld.
(2) I would also like to understand how resources are deprovisioned.
What happens when a provisioned resource's allocated time has lapsed?
Are there any plans for an implementation of an official deprovisioning
process (e.g., VCL::Module::Provisioning::unload( ))?
Deprovisioning already happens and is handled by reclaim.pm. The process
depends on whether or not a user logged into the computer, which can be
determined by the value of request.laststate.
If a user logged in, the computer needs to be completely reloaded. You'll know
this if request.laststate = inuse. If reclaim.pm detects this, it inserts a
reload request for the computer into the database and exits.
If reclaim.pm sees that request.laststate is not inuse, it means the user
never logged in and it's safe to attempt to sanitize the computer without
reloading it. reclaim.pm will call the OS module's sanitize() subroutine. If
successful, the computer state is set to available and can be used for another
reservation. If sanitize() fails, reclaim.pm inserts a reload request into the
database and exits.
Hope this helps,
Andy
Toks
--
Andy Kurth
Virtual Computing Lab
Office of Information Technology
North Carolina State University
andy_ku...@ncsu.edu
919.513.4090
