You probably want to trace through and - if you haven't already, but I'll summarize below.

At a minimum you should have these routines:

node_status - checks/confirms status of node - returns ready or reload
does_image_exist - checks image repos - for image files/templates, etc calls retrieve_image if needed
load - loads the vm
capture - image creation

These routines are internal to
retrieve_image - in a multiple management node/image library setup - fetches image files via scp
control_VM - sort of your de-provisioning , turns off removes vms
get_image_size - for recording in the database image/imagerevision table

We have a few questions:

1)  Where does the responsibility of the provisioning module stop.  Right
now we have the module copying the files, registering the VM, and turning
it on.  Do we need to do anything else, or is that too much?  (such as
waiting for the machine to boot before returning)

The provisioning module is responsible for making sure the node is up, running and accessible.

Then returning success/failure to the new module.

So it would need to:
* setup any files - copy, register
* start the load - turn on
* make sure it's loading - checking the vm state, checking any log files, etc and recording the state via using the insertloadlog routine. * wait until the vm is ready for use - perform any post actions, make sure firewall settings are right, randomize the passwords for the admin accounts(root[if being used],administrator). In the and this a loop with counters to prevent any infinite loop scenarios
* return success/failure to the calling state(new/reclaim)

Then will proceed to either add users, create image, or mark node as available depending on the requested state (new,reload,image)

2)  How do we deal with cleaning a hypervisor up after the reservation is
complete?  With the current architecture, there is no deprovisioning API
for the modules, which VCL could call when a reservation is done, so we
can unregister and clean up the VM. That would seem like the best way to
do this, but until then, we need to find a workaround. Since VMs are
currently based on slots, we can identify them by their slot name/number
and clean them up when the next provisioning load event happens for that
slot.  Does this sound like an appropriate solution for now?

This is initiated through reclaim - by inserting a reload request.

The logic in load routine is to first call control_VM("remove")

load is only called if it needs to be loaded - either new load or reload after a reservation, or wrong image is loaded. Whether it needs to be loaded/reloaded determined by node_status

3)  What variable is the slot name/number in the datastructure handed to
the module?

not sure I understand, are you referring to the node name and it's details?

by using

you can get pretty much any variable in the data hash. Look in lib/VCL/ for the list of variables that can be retrieved

4)  How should the virtual machines users get setup with our module?  Are
the OS module components functional enough, or do we need to add code in
our provisioning module for this?

This is split up right now and we should probably make this more generic.

- for new requests, once a node is ready(vm,blade,standalone lab machine)
If it is windows OS - the add_user routine is called, this adds a user to the windows OS. If it is Linux OS - add_user is called in when user acknowledges reservation

In reserved. two methods new and old
once the user hits the "connect" button (acknowledges the reservation)
if ($self->os->can("grant_access"))

Andy add more if I'm missing something
grant_access comes from the os module - this routines opens the firewall with the users incoming src IP

Hope this helps.

If you can send the code chunk in (maybe in a sandbox branch) - we can look over it.


Reply via email to