VNFS

The Virtual Node File System began as a simple chroot in the early Warewulf days. As Warewulf and the idea of the Virtual Node chroot (or file system) matured, the importance of the VNFS became apparent. Warewulf utilized scripts to create and do initial configuration of VNFS images which was nice from the distribution perspectives, but caused problems with reproducibility and cross platform VNFS creations.

Another major limitation with Warewulf's implementation of the VNFS was that the kernel was inherently separate from the VNFS image. Meaning, that Warewulf would utilize the kernel from the master's underlying OS (thus the kernel you want to boot your nodes must be installed on the master). This model seems logical at first, but quickly limits the combinations of distribution/kernel relationships that can be maintained.

Introduction of the VNFS capsule

Different from the VNFS image (which is basically just a chroot) Perceus introduced the VNFS capsule. The capsule not only contains the chroot image, but also all of the necessary provision scripts, kernel and kernel modules, and other configuration tools. This means that the VNFS itself controls its own methods for provisioning, setup, hardware support, application support, etc.

The VNFS capsule allows us now to maintain what goes on the node file systems, offer support models for that, and allow us to delivery complete solutions.

Provisionary State

Nodes contact the Perceus daemon from a variety of states depending on what the node is doing at that time. For example, the init state is hard coded in Perceus and it tells the Perceus daemon that the system is now ready to be provisioned. Another provisionary state that is used (but not hard coded) is the ready state.

The provisionary state is communicated to the Perceus daemon via the Perceus client daemon which will run on the nodes inparticular. The client will contact the master with its provisionary state, and the master will send the client what it should do in that state.

The module command makes use of the provisionary state in the form of a heariachy. For example, init/all means all nodes will run that module when they are provisioned. On the contrary, init/group/foo means that only nodes part of group foo will run this module.