[X] This bug report is not security related, security issues should be disclosed privately via netbox operator maintainers.
[X] Existing open issues have been checked and this is not a duplicate.
What happened?
Under some circumstances, the parent prefix will be computed but already exhausted. Even if you add more prefixes, the system will not recover and compute/choose a new parent prefix.
If the selected parent prefix is already exhausted, the system should recover and compute/choose a new parent prefix.
How can we reproduce it (as minimally and precisely as possible)?
It's a bit of a race condition.
You need to apply a PrefixClaim, and on NetBox you reserve all Prefixes available within the potential candidates, and hopefully this can be done before PrefixClaim starts claiming the first available prefix.
Bug report criteria
What happened?
Under some circumstances, the parent prefix will be computed but already exhausted. Even if you add more prefixes, the system will not recover and compute/choose a new parent prefix.
See https://github.com/netbox-community/netbox-operator/pull/90#issuecomment-2475877803
What did you expect to happen?
If the selected parent prefix is already exhausted, the system should recover and compute/choose a new parent prefix.
How can we reproduce it (as minimally and precisely as possible)?
It's a bit of a race condition.
You need to apply a PrefixClaim, and on NetBox you reserve all Prefixes available within the potential candidates, and hopefully this can be done before PrefixClaim starts claiming the first available prefix.
Netbox operator version
Latest on main (the issue was discovered on https://github.com/netbox-community/netbox-operator/pull/90 before merging)
Netbox operator configuration (command line flags or environment variables)
No response
Relevant log output
Anything else we need to know?
Maybe we could fix this by removing
.status.parentPrefix
if we come to the condition that has the message "parent prefix exhausted"