Closed roivanov closed 9 months ago
Can you explain your reasoning for this PR? Running the default site.yaml
will always run the system configuration steps. Are you attempting to only apply the system steps, make changes before installation of K3s, then apply the full install?
Can you explain your reasoning for this PR? Running the default
site.yaml
will always run the system configuration steps. Are you attempting to only apply the system steps, make changes before installation of K3s, then apply the full install?
User may have a case when a node was added manually to the cluster. And so user didn't pay close attention applying some/most of the configuration settings. This change should allow bringing such nodes in-sync with those configured by the script initially while skipping K3s installation steps.
This can already be accomplished with the default playbook. You just need to add an additional group to your k3s_cluster in your inventory. Here is an example:
k3s_cluster:
children:
server:
hosts:
192.168.1.91:
agent:
hosts:
192.168.1.93:
manual:
hosts:
192.168.1.92:
The name of the subgroup doesn't matter, as long as its not server
or agent
. We run the Cluster-Prep on every target in the k3s_cluster
Making a dedicated inventory of manual.yml
would prevent you from rerunning k3s installation on you existing inventory.
k3s_cluster:
children:
manual:
hosts:
192.168.1.92:
Re-apply system configuration setting playbook added. User may have a case when a node was added manually to the cluster. And so user didn't pay close attention applying some/most of the configuration settings. This change should allow bringing such nodes in-sync with those configured by the script initially while skipping K3s installation steps.
Changes
Linked Issues