Thanks for your detailed responses Andy.
Toks
Andy Kurth wrote:
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
