Module Design Guidelines

The toolkit itself was designed around some basic principles. The modules that were initially created alongside the toolkit also followed this style. While every module developer has the option of going down their own path, the following should be at least considered and followed if possible.

Module Coverage

Each module should cover a particular scope of an application, preferably without replicating the functionality available in another module. In addition, a module should be appropriately sized; if the module can be sensibly broken into sub components, then smaller modules should be created instead of one large monolithic module.

For example: A designer may decide to write a module to provide security services to a target server installation. As part of this module, the designer decides to install a firewall and a set of hardening scripts.

In this case, the designer should investigate whether another module already covers either of these two areas and could be leveraged. In addition, if either the firewall or hardening scripts may be used elsewhere in isolation from each other, it may be more flexible to create them as two modules rather than bundling them together.

Module Dependencies

Each module should be self sufficient and not expect or rely on another module to be present. If such interaction is required (and sometimes it does make sense), then the module should be clearly identified as being dependent on the other module. If the situation does arise, it should be determined whether the functionality is best represented in distinct modules or whether the two modules that are dependent on each other are better represented in one encompassing module. The basic premise is to keep items together where it makes sense and not to create lots of smaller modules just for the sake of it.

Module Interactions

Where the case is strong for module separation and the modules are dependent (in at least one direction), the modules should try to interact with each other so that the correct (desirable) outcome is achieved. The toolkit has a simplistic mechanism for setting and retrieving hints on a per module basis. Whether a module will pick up the hints, is up to the designer of the module, but with cooperation between module developers, the modules can be written in such a way that they work happily in isolation, but when put together they provide a stronger solution.

For example: From a real-world example, the Sun Cluster 3 product places dependencies on how Solstice DiskSuite is configured, but does not always need DiskSuite installed, nor does DiskSuite require the cluster software installed indeed it is very valuable to be installed on non-clustered machines.

In this case, we have two very distinct modules; one that covers DiskSuite and one that covers the Sun Cluster product. Each works fine in isolation, but when they are combined within the same target server configuration, the Sun Cluster module influences the DiskSuite module so it conforms to the restrictions placed on DiskSuite by Sun Cluster 3.0.

This interaction is done through the use of module hints and their behavior in the standalone scenarios can be summarized as follows:

• When only the Sun Cluster module is active, Sun Cluster sets the hints, but DiskSuite is not present to pick them up

• When only DiskSuite is active, it looks for the hints, but they have not been set by any other module, so it uses it's regular default behavior.

What the hints actually represent is totally up to the module developer. Close cooperation between module developers will enable the most efficient use of hints; if possible, the hints should be documented within the module Release Notes, so other module developers may take advantage of the additional interfaces.

Module Coding

The module developer should try to select a standard scripting language that will be available during the JumpStart installation. For example, the use of a 'bash' is not possible, as the NFS boot image the target server uses does not contain that shell.

Where possible, the Bourne Shell should be used as this is know to exist on all versions of Solaris. Only as a last resort should a compiled language be considered.