Some applications must run as a single instance per node. Their image declares this with the org.nethserver.max-per-node label: for example CrowdSec has org.nethserver.max-per-node=1, because two instances on the same node make no sense and compete for the same resources.
The Software Center respects this limit and does not offer nodes that already have the maximum number of instances. The add-module command, instead, ignores the label: an administrator (or an automated tool, like an AI agent) can install a second CrowdSec instance on the same node without any warning. This is an easy mistake to make, and it is not obvious to administrators who expect the command line to follow the same rules as the web interface.
Proposed solution
- By default,
add-module checks the org.nethserver.max-per-node label of the image and refuses to install a new instance on a node that has already reached the limit. It prints a clear error message that names the limit and the existing instances.
- A new
--force option keeps the current behavior, skipping the check. This is useful for developers and for special cases.
- The check should apply to both module names from the repositories and explicit image URLs.
- Document the
--force option in the developer manual.
Alternative solutions
Leave the command as it is and only document the limitation. This does not prevent the mistake.
Additional context
The same limit is already computed for the Software Center by the list-modules action (install destinations with reject reason max_per_node_limit), so the logic can be reused.
Some applications must run as a single instance per node. Their image declares this with the
org.nethserver.max-per-nodelabel: for example CrowdSec hasorg.nethserver.max-per-node=1, because two instances on the same node make no sense and compete for the same resources.The Software Center respects this limit and does not offer nodes that already have the maximum number of instances. The
add-modulecommand, instead, ignores the label: an administrator (or an automated tool, like an AI agent) can install a second CrowdSec instance on the same node without any warning. This is an easy mistake to make, and it is not obvious to administrators who expect the command line to follow the same rules as the web interface.Proposed solution
add-modulechecks theorg.nethserver.max-per-nodelabel of the image and refuses to install a new instance on a node that has already reached the limit. It prints a clear error message that names the limit and the existing instances.--forceoption keeps the current behavior, skipping the check. This is useful for developers and for special cases.--forceoption in the developer manual.Alternative solutions
Leave the command as it is and only document the limitation. This does not prevent the mistake.
Additional context
The same limit is already computed for the Software Center by the
list-modulesaction (install destinations with reject reasonmax_per_node_limit), so the logic can be reused.