What
Config changes applied to a running node (profiles, root_leaf_issuance, revocation settings, operator profiles) are staged but do not take effect until the node reboots: ApplyNodeConfig returns requires_reboot: true, and GetNodeConfig immediately reflects the staged values (misleading), but the live signer keeps the booted config. The manager/web has no way to reboot a node, so an operator cannot activate the change from the web (I had to power-cycle out of band).
Why
Observed repeatedly during live ESXi validation (S5/S6/S9): a leaf profile, the root-leaf-issuance acknowledgement, and operator profiles all only became active after a reboot. Full web parity needs either a node reboot action (guarded) or a clear "staged, pending reboot" surface plus a way to trigger it.
Related: a freshly ferry-established subordinate also cannot be decommissioned until it reboots — the node captures its confirm CN at boot, so it is stale until the identity is reloaded.
Part of #24.
What
Config changes applied to a running node (profiles,
root_leaf_issuance, revocation settings, operator profiles) are staged but do not take effect until the node reboots:ApplyNodeConfigreturnsrequires_reboot: true, andGetNodeConfigimmediately reflects the staged values (misleading), but the live signer keeps the booted config. The manager/web has no way to reboot a node, so an operator cannot activate the change from the web (I had to power-cycle out of band).Why
Observed repeatedly during live ESXi validation (S5/S6/S9): a leaf profile, the root-leaf-issuance acknowledgement, and operator profiles all only became active after a reboot. Full web parity needs either a node reboot action (guarded) or a clear "staged, pending reboot" surface plus a way to trigger it.
Related: a freshly ferry-established subordinate also cannot be decommissioned until it reboots — the node captures its confirm CN at boot, so it is stale until the identity is reloaded.
Part of #24.