Node Profiles
Profiles provide a way to scalably group node configurations together. Instead of redundant configurations for each node, you can put that into a profile and the nodes will inherit these configurations. This is very handy if you have groups of node specific customizations. For example, a few hundred nodes that are running a particular container or kernel, and another group of nodes that are running a different kernel or container.
Any node configuration attributes can be applied to a profile, but there are always going to be some node configurations which must be specific to a node, like a network HW/MAC address or an IP address.
An Introduction To Profiles#
Every new node is automatically added to a profile called default. You can view the configuration attributes of this profile by using the wwctl profile list command. Like the wwctl node list command, this will provide a summary, but you can see all configuration attributes by using the --all or -a flag as follows:
And with the -a flag:
As you can see here, there is only one attribute set by default in this profile, and that is the "Comment" field. That Comment is inherited by any nodes that are configured to use this profile. So if we look at the node we configured in the last section, we can see that configuration attribute there:
Here you can see that the "Comment" attribute was inherited by this node, and it also provides you with the information of which profile this attribute was inherited from. This is very useful information as nodes can be part of multiple profiles with inheritance being cascading.
Multiple Profiles#
For demonstration purposes, let's create another profile and demonstrate how to use this second profile.
Now that we've created a new profile, let's create a configuration attribute in this profile:
Lastly we just need to configure this profile to our node(s):
And you can now verify that the node has both profile configurations:
Cascading Profiles#
In the previous example, we set a single node to have two profile configurations. We can also overwrite configurations as follows:
And if we delete the superseded profile attribute from test_profile we can now see the previous configuration:
This is a very useful feature for dealing with many groups of cluster nodes and/or testing new configurations on smaller subsets of cluster nodes. For example, you can use this method to run a different kernel on only a subset or group of cluster nodes without changing any other node attributes.
Overriding Profiles#
All profile configurations can be overwritten by a node configuration as can be seen here:
How To Use Profiles Effectively#
There are a lot of ways to use profiles to facilitate the management of large cluster node attributes, but there is nothing inherent in the design of Warewulf that requires use of them for anything. It is completely reasonable to not use profiles at all to help with node configuration attributes.
But if you do wish to use profiles, the best way to use them is to manage "fixed" configurations of groups of cluster nodes. For example, if you have multiple sub-clusters in your cluster, it might be advantageous to have a cluster_name profile which includes things like network configurations, and/or a specific kernel, container, boot arguments, etc.
Node specific information, like HW/MAC addresses and IP addresses should always be put in a node configuration rather than a profile configuration.