metal-api
metal-api copied to clipboard
API to manage and control plane resources like machines, switches, operating system images, machine sizes, networks, IP addresses and more
 ``` $ kubectl get pods -A|grep metal-d metal-control-plane metal-db-0 2/2 Running 0 4h43m $ kubectl get pods -A|grep metal-api metal-control-plane metal-api-69c7c48557-6v4r8 1/1 Running 0 4d12h metal-control-plane metal-api-69c7c48557-8vscq 1/1 Running...
There are two possibilities to get into a state where you have a machine that you cannot reach over the network after the allocation: 1. We register a new switch...
Actually these machines are counted as free/waiting which is wrong.
This events happen very often and they should not interfere with regular switch write operations, which are way more important to proceed.
You have to wait for 30 minutes or so until someone can use the API again when this happens. On startup we should retry more often?
I saw that the retries from the `github.com/avast/retry-go/v4` dependency can take up to 60 seconds by default. This is longer than our default HTTP timeout, which could lead to misleading...
This helps to either specify more exact sizes or create initial sizes for a new machine type. ```bash $ metalctl size suggest constraints: - max: 8 min: 8 type: cores...
It contains private addresses of other partitions with /32 notation. This yields in utterly long FRR route-maps.