kelvin/warewulf
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Reflow all userdocs text

Browse Source 
Signed-off-by: Jonathon Anderson <janderson@ciq.co>
This commit is contained in:
Jonathon Anderson
2023-02-22 00:02:08 -07:00
parent 3d7438bc6c
commit ef31b3ddb8
24 changed files with 1005 additions and 362 deletions
Download Patch File Download Diff File Expand all files Collapse all files

69
userdocs/contents/profiles.rst
View File

@@ -2,14 +2,27 @@
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.
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.
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:
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:
.. code-block:: bash
@@ -43,7 +56,11 @@ And with the ``-a`` flag:
default IpmiUserName --
default IpmiInterface --
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:
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:
.. code-block:: bash
@@ -54,12 +71,17 @@ As you can see here, there is only one attribute set by default in this profile,
n0000 Comment default This profile is automatically included for each node
n0000 Cluster -- --
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.
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.
For demonstration purposes, let's create another profile and
demonstrate how to use this second profile.
.. code-block:: bash
@@ -70,7 +92,8 @@ For demonstration purposes, let's create another profile and demonstrate how to
default This profile is automatically included for each node
test_profile --
Now that we've created a new profile, let's create a configuration attribute in this profile:
Now that we've created a new profile, let's create a configuration
attribute in this profile:
.. code-block:: bash
@@ -102,7 +125,8 @@ 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:
In the previous example, we set a single node to have two profile
configurations. We can also overwrite configurations as follows:
.. code-block:: bash
@@ -117,7 +141,8 @@ In the previous example, we set a single node to have two profile configurations
n0000 Cluster test_profile cluster01
n0000 Profiles -- default,test_profile
And if we delete the superseded profile attribute from ``test_profile`` we can now see the previous configuration:
And if we delete the superseded profile attribute from
``test_profile`` we can now see the previous configuration:
.. code-block:: bash
@@ -132,12 +157,17 @@ And if we delete the superseded profile attribute from ``test_profile`` we can n
n0000 Cluster test_profile cluster01
n0000 Profiles -- default,test_profile
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.
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:
All profile configurations can be overwritten by a node configuration
as can be seen here:
.. code-block:: bash
@@ -155,8 +185,19 @@ All profile configurations can be overwritten by a node configuration as can be
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.
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.
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.
Node specific information, like HW/MAC addresses and IP addresses
should always be put in a node configuration rather than a profile
configuration.