The task of parallelization of imaging basically involves running multiple instances of nodeHandler which would launch different images on different nodes. The basic sequence of imaging of nodes as of now is as follows:

1. The user runs the script imageNodes with the nodes and the image to be loaded as inputs.
2. The parameters are passed on to the nodeHandler which then resets the specific nodes using cmc.
3. It also launches the frisbee server from the tftpboot which sends out the particular image on a multicast address and creates tftp links to the node to provide nodes with the memory based image.
4. On the node side, the nodes when started boot into the memory image and then launch the frisbee client.
5. The frisbee client fetches disk chunks from the frisbee client and writes it to the hard disk.
6. The tftp links for the nodes are then removed.
7. From now on the nodes boot up from the image stored in the hard disk.

The imaging of nodes in parallel involves launching multiple instances of nodehandler which in turn implies launching more than one frisbee servers with different multicast addresses throwing away different images. At present the frisbee server settings are such that one multicast address per domain is allowed. For e.g. if a user is using a sb only one multicast address for a particular sb is allowed. So in case a user runs a second imageNodes in parallel, the frisbee server fetches the same nulticast address that results in an error. Thus the basic steps involved in parallelization would be :

1. Tweaking the way frisbee server is launched, so that even if two frisbee servers are launched in the same domain, they throw images on different multicast addresses.
2. Making appropriate changes in nodeHandler.rb since right now the script only allows one instance of nodeHandler to run at a time.

An alternative approach could be launching the frisbee server and client manually for different images. On a high level the basic steps involved would be:

1. Create the tftp links to the nodes manually so that the nodes can boot into the memory based images.
2. Launch the frisbee servers from tftpboot in reposotory2 using different multicast addresses.
3. Launch the frisbee client on the nodes manually, with multicast addresses corresponding to the images to be loaded.

As a first step, some changes have been made to the imageNodes shell script which result in the identification of any concurrent running instance of nodeHandler. If the nodeHandler is already being run, it gives out a warning message to the user and exits. The nodeHandler in the meanwhile continues the imaging of the nodes. In case nodeHandler is not running, it will go ahead and image the nodes as specified. The modified imageNodes (imageNodes_new) is attached at the end of the page.

Date : 9/19/06

To image the nodes in parallel, instead of running multiple instances of nodeHandler, we are trying to bypass the nodeHandler itself and. The basic three functions of the nodeHandler

1. Creating soft links with the node to server the basic memory based image,

2. Launching the frisbee server

3. And reseting the respective nodes.

will now be performed by the shell script imageNodes itself.

All these three commands can be executed using the xml querries at the command line. The querries for these three operations are:

For creating soft pxe links with a particular node:

​http://pxe:5012/pxe/getAddress?img=<image name>&node≤node ID>&ip≤ip address of node>

For launching the frisbee server:

​http://frisbee:5012/frisbee/getAddress?img=<image name to be launched>

In case the image is already launched, it will return the multicast address and port number for that image. If not it will launch that image on new port number and a default multicast address. Since new images are launched on new port, different multicast addresses for different images are not required.

Similarly the cmc service can be used to reset the nodes as follows:

​http://cmc:5012/cmc/reset?x=<x co-ordinate of node>?&y≤y coordinate of node>

To implement these changes the imageNodes has been changed a bit.

1. On running imageNodes it fisrt checks for the domain its running on and the nodes on which it has to serve the soft pxe link. It then creates a soft link using the pxe server, with the subnet number of the domain itself.

2. It then launches the frisbee server on the tftpboot and starts giving out the image specified at the command line.

3. Resets the specific nodes using cmc.

The changed copy of imageNodes is attached at the end of the page.