Luna profiles

A profile is a named set of files, with their path, owner and mode on the node, and optionally a service on the node to act on once the files are in place. Profiles are assigned to groups and to nodes, applied when a node installs and delivered live to nodes that are already running. They carry the small configuration a site needs on every node — a motd, a kernel tunable, an exporter's configuration, a client's settings — without a role, a playbook or an image rebuild.

Profiles and secrets follow the same rules: both stack. A node applies its group's profiles and its own, unlike most Luna settings where the node's value replaces the group's. Secrets are for material that must not be readable; profiles are for ordinary configuration.

Defining a profile

# luna profile addfile motd motd -p /etc/motd -qc /root/motd.txt
# luna profile addfile sysctl-hpc 90-hpc.conf -p /etc/sysctl.d/90-hpc.conf -qc "vm.swappiness = 1"
# luna profile change sysctl-hpc --service systemd-sysctl --action restart
# luna profile show sysctl-hpc
# luna profile list

addfile creates the profile with its first file when it does not exist yet. A file takes --owner (user or user:group, names or numeric ids; default root:root) and --mode (octal, default 644). Content comes from a file, inline, or from $EDITOR with -c. changefile and removefile edit the set; clone, rename and remove act on the whole profile.

A profile may name one service and what to do with it — restart, reload, start, stop or none — after its files are written. The service is a systemd unit on the node.

Names in --owner are resolved to numeric ids on the controller, so a user that exists in the directory but not in the image is still applied correctly. Where the controller has no directory and the nodes do, give the ids as numbers.

Assigning

# luna group change compute --profiles motd,sysctl-hpc
# luna node change node001 --profiles debug-tools
# luna profile member sysctl-hpc

node001 ends up with motd, sysctl-hpc and debug-tools. A profile that is assigned cannot be removed; unassign it first.

When it lands

  • At install, every assigned profile is written into the image before the node pivots, and its service is enabled.
  • Live, on a node that is already running: assigning, changing or unassigning a profile queues a delivery from the active controller. The node writes the files, keeps a backup of what was there before, and performs the service action once. A node that cannot be reached is retried at intervals; status shows it.
# luna profile status
+-----------------------+
|  << Profile Status >> |
+--------------+--------+
|    state     | nodes  |
+--------------+--------+
|   in sync    |   61   |
|   behind     |    2   |
|   failed     |    1   |
+--------------+--------+

# luna profile status --all
# luna profile status node001
State Meaning
in sync the node holds exactly the profiles it is assigned
not applied nothing assigned, nothing delivered
behind a delivery is due or under way; the detail says why it waits, for instance a node mid-install
failed the last delivery failed; it is retried
given up the retries are exhausted; the detail says why
frozen in sync, and one of its profiles is disabled

Disabling and unassigning

--enabled n freezes a profile: the nodes that hold it keep its files exactly as they are, and nothing — not an edit, not a service action — reaches them until it is enabled again. That is how a profile is built up before it rolls out, and how Luna is stopped from acting on something in production without ripping it off the nodes.

Only removal reverts: unassigning a profile from a node or its group, dropping a file from it, or deleting the profile. A file that existed before the profile is restored from the node's backup; a file that did not is deleted; the service action runs once more.

Limits worth knowing

  • A hand edit to a profile-managed file on a node is not noticed; profiles are enforced at delivery, not continuously. Such an edit is lost when the profile is unassigned, because the pre-profile original is what is restored.
  • Nodes the controller cannot reach inbound — cloud, NAT, remote sites — are served at install and converge at their next reinstall.
  • On a node that runs from RAM the backup does not survive a reboot; those nodes re-provision on boot, so the image supplies the original instead.