I was assigned the work of reproducing the planet lab-orbit integration demo. I have the following updates:
 
   1. I understood the planet lab documentations.
   2. I also ran several experiments on the orbit to get familiarised. Was able to extract the results using OML.  
   3. I understood the changes made to the nodehandler script for the planetlab node integration and the other scripts of the experiment.
   4. The demo was not running because two of the planetlab nodes seem to be down and the third one doesnt seem to have Apache loaded. So I am working    on getting the Apache loaded onto the server. Also contacted Ivan for removing the firewalls on the sandboxes, so that I can get more access to the orbit. 
   5. Working on getting the demo to run and then make a plan to decide the appropriate changes to be made to the node Handler script as a part of the integration.



9/17
----
   1. Ran the planet lab- orbit integration demo.
    - Learnt to set up an Apache server.
    - Learnt the VLC commands for server , relay and client.
   2. Ran the experiment manually- learnt to  configure the nodes manually. 
   3. Installed pssh on the grid console and ran all the commands pssh,pnuke and pscp
   4. Presently reading the nodehandler and agent scripts and trying to understand the nodehndler architecture.

9/24
----
   1. Made the necessary changes in the demo scripts that were hardcoded and saved a copy of the new OS.
   2. Experimented with Pssh and Gexec on the planetlab nodes.

    PSSH

-- Mainly for controlling large collections of nodes in the wide-area. 
-- Has proven to be a better option for large collection of nodes like the Planet-Lab.
-- Is built over ssh, hence does not need to run on the client side.
-- Provides features like parallel copy pscp, and parallel process killing using pnuke.
-- It is slow and all the resources are in the central server.
-- Can ssh to 32 clients at a given time. 
-- It actually runs parallel processes that ssh to the individual nodes.

    GEXEC

-- Faster as the resources are distributed.
-- GEXEC operates by building an n-ary tree of TCP sockets and threads between gexec daemons and propagating control information up and down the tree.
-- By using hierarchical control, GEXEC distributes both the work and resource usage associated with massive amounts of parallelism across multiple nodes, thereby eliminating problems associated with single node resource limits (e.g., limits on the number of file descriptors on front-end nodes)
-- It uses a client server model, hence was installed on all the planet lab nodes. The gexec daemon has to run on all the planet-lab nodes.   


10/2
----

  1. Understood the CMC service scripts and the XML interface with ruby. 
  2. Wrote a sample script for the resource manager that interacted with the user using http.
  3. Trying to come up with an algorithm for slice reservation and to use ruby or C++ to implement the algorithm

-- Ruby --
- Lack of data structures
- Easy XML interface
- Easy SQL interface. 

-- C++ --
- Very good hash functions. Hash structures can be used for reservation management.




10/9
----

   1. Compiled the initial document for the Resource Manager.
   2. Wrote ruby scripts for the user interface for the Resource Manager.
   3. Went throught the present php scheduler code. Decided that the present scheduler can be modified for multiple reservations.