Through the use of invalid hostnames it is currently possible to deactivate individual nova-compute services.
We use the release Rocky on an environment. If we start an instance with an invalid hostname, the nova-compute service detects this and throws an exception.
The builder failure weigher (activated by default) blocks the nova-compute service from further instances. You have to restart the nova-compute service or explicitly start an instance on this node for the service to work again.
In other words, it is possible that an unprivileged user blocks an internal component due to an incorrect input. In principle you can deactivate whole environments with it.
We have now temporarily solved this problem by setting build_failure_weight_multiplier to 0.
However, we think that invalid names should already be identified by the API when creating the instance and should not lead to unwanted behavior within the environment. Therefore we open this report again.
Through the use of invalid hostnames it is currently possible to deactivate individual nova-compute services.
We use the release Rocky on an environment. If we start an instance with an invalid hostname, the nova-compute service detects this and throws an exception.
The builder failure weigher (activated by default) blocks the nova-compute service from further instances. You have to restart the nova-compute service or explicitly start an instance on this node for the service to work again.
In other words, it is possible that an unprivileged user blocks an internal component due to an incorrect input. In principle you can deactivate whole environments with it.
We have now temporarily solved this problem by setting build_failure_ weight_ multiplier to 0.
However, we think that invalid names should already be identified by the API when creating the instance and should not lead to unwanted behavior within the environment. Therefore we open this report again.