If an NNCP policy is defined that matches multiple nodes (via nncp.spec.nodeSelector), we have the ability to roll out the policy gradually by setting nncp.spec.maxUnavailable field. The maxUnavailable field instructs the NMState operator to update only a subset of the cluster nodes and execute probes to verify that the update didn't break the node's connectivity before continuing updating the remaining cluster nodes.

If using a separate NNCP policy per node, there is currently no possibility to update the nodes gradually. As soon as the nncp policies are updated, all matching nodes are updated simultaneously. The nncp.spec.maxUnavailable field is not usable in this scenario as this field is bound to a single policy.

This feature request is asking to introduce an equivalent of the maxUnavailable field for controlling node updates when a single NNCP policy per node is used.

From a broader perspective, it seems that for rolling out updates the NMState operator could use a model similar to the MachineConfig/MachineConfigPool. In this model, a MachineConfig (equivalent to NNCP) defines a piece of configuration that should be applied to a node. The MachineConfig operator compiles all such pieces per node and renders a full configuration for each node first. After that the configuration is applied to the individual cluster nodes in a controlled fashion. The MachineConfigPool.spec.maxUnavailable controls the gradual roll out. This approach of rendering the full node configuration first has also the benefit that it doesn't run into configuration dependency issues. The full node configuration is applied to a given node at once as opposed to individual policies being applied to the node separately.