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 Kurth
Virtual Computing Lab
Office of Information Technology
North Carolina State University

Reply via email to