Dynamically add packages on the server

[Takeshi Kobayakawa]

I began using PelicanHPC to build a cluster system, and successfully can netboot the system.
Now, what I would like to do is to dynamically add debian packages, i.e. without rebooting the clusters. I tried
     aptitude install packagename
by chroot-ing to the $ARCH/frontend/chroot directory in the server. However, clusters cannot see the newly installed packages. How should I configure the package, so as to the clusters can dynamically see the changes in the server export directory? I suppose it is something to do with the configuration of aufs, but I could not figure out how root directory of cluster is configured.

[Michael Creel]

The way to make new packages available to the compute nodes is to install new software into /home/user. This requires some work to make the .debs use non-default locations. Please see the the first entry on "highlights from the forum" on the homepage (pelicanhpc.ord). If you compile from source, it may be easier, since you won't have to to repackaging of the .debs.

The alternative is to make your own version using the make_pelican script. Add the needed packages, and make a customized iso image.

I don't advise trying to modify the aufs file, I have never tried to do that because I doubt that it will work. I think the above two methods will be quicker and easier.

[Takeshi Kobayakawa]

Thank you for a kind reply. I understand how to add packages to /home/user directory. But it needs repackaging.
By the way, I also tried on the original debian-live system to add
lh_config --chroot-filesystem plain
then it uses plain nfs instead of squashfs. Then I could chroot and add packages by aptitude on the frontend(=server). The compute node could see those packages added on the frontend without rebooting.
I have not tried this to PelicanHPC. Is it hard or out-of-scope to suppose such kind of operation to the clusters? This approach doesn't need repackaging, but sometimes files are hiddend under ramfs(cow). When you confront problems, then reboot. I haven't experienced any operations, but will try.

[Michael Creel]

Using lh_config --chroot-filesystem plain is an interesting idea. From experience with Knoppix, I believe that NFS export of the squashfs compressed filesystem has advantages in that network traffic is less than it would be if plain NFS is used, but this is very much a combination of soft data, hearsay, and imagination. If plain NFS works well on a moderately sized cluster, I would be very interested to know about it.

[Shporang]

I would imagine it would be possible to use ksysgaurd to check.

A couple of ways to do this come to mind:
1)You could try running 2 smaller, separate clusters simultaneously, an monitor your network usage (obviously impractical)
2)You could try taking screen shots of your network usage under different scenarios (more/fewer nodes, running short/long jobs/idle, compare plain fs to squashfs, ect) obviously you would have to reboot for each fs you test.
3)And finally it may be possible to write some script to collect data to a log file, and display some measurement (average usage, median usage, modal usage, or some similar setup) Not sure about this last one, but if possible it would likely be most useful coupled with the previous setup.

I think it would be rather interesting to see the results.