API uses cluster_id inconsistently
/api/compute_resources/:id/available_clusters/:cluster_id/available_networks for different Compute Resources,
cluster_id has different meanings, which makes writing a client harder than it should be.
On oVirt/RHV, it's the
/api/compute_resources/:id/available_clusters, which seems logical.
On VMware, it's the
name (or maybe
full_path, on all cluster I have access to, those are identical), which is pretty off for my understanding of "ID" :)
On Google, the cluster id is completely ignored.
I only tested this on 2.1, but expect it to be present in other releases too.