| | 17 | 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 : |
| | 18 | |
| | 19 | 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. |
| | 20 | 2. Making appropriate changes in nodeHandler.rb since right now the script only allows one instance of nodeHandler to run at a time. |
| | 21 | |
| | 22 | 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: |
| | 23 | |
| | 24 | 1. Create the tftp links to the nodes manually so that the nodes can boot into the memory based images. |
| | 25 | 2. Launch the frisbee servers from tftpboot in reposotory2 using different multicast addresses. |
| | 26 | 3. Launch the frisbee client on the nodes manually, with multicast addresses corresponding to the images to be loaded. |
| | 27 | |
| | 28 | 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. |
