In order to ensure we are properly rack-redundant we need to make sure cloudvirt capacity is spread out evenly across racks. This is my understanding of the situation today, according to data gathered from openstack APIs. (I'll be sending out for review the cookbook I used)
| Rack | Hosts | VMs | vCPU used/total | vCPU% | RAM used/total | RAM% |
|---|---|---|---|---|---|---|
| D5 | 8 | 154 | 867/576 | 151% | 2053.0/4028.1 GiB | 51% |
| E4 | 14 | 345 | 1504/952 | 158% | 3318.0/7044.1 GiB | 47% |
| F4 | 15 | 362 | 1703/1016 | 168% | 3943.0/7547.5 GiB | 52% |
I don't know the full history here of why C doesn't have any cloudvirts; though shuffling capacity to rack C will ensure we can drain a full rack and still have reasonable headroom in the remaining racks, including taking into consideration {T412418} which will refresh cloudvirt104[0-6] (72core / 512GB ram) with 4 hosts (128core / 1TB ram).
There are a few possibilities on the new hardware allocation, though I think the new hosts should be spread out across racks for sure. The hosts to be refreshed are all in D so there will be moves to do from other racks, in the order of 15 moves if we chose to do it and achieve more or less balanced RAM spread.
Below is a table showing the final hardware allocation I (Filippo) am suggesting, with the refreshed cloudvirts (104[0-6]) already out of the picture
| Rack | Hosts | Host List | vCPU Total | RAM Total |
|---|---|---|---|---|
| C8 | 8 | new(1077), 1048, 1049, 1051, 1054, 1055, 1056, 1057 | 632 | 4608 GiB |
| D5 | 8 | new(1078), 1047, 1065, 1066, 1067, 1072, 1073, 1074 | 632 | 4608 GiB |
| E4 | 9 | new(1079), 1062, 1063, 1064, 1068, 1069, 1070, 1071, 1075 | 640 | 5120 GiB |
| F4 | 9 | new(1080), 1050, 1052, 1053, 1058, 1059, 1060, 1061, 1076 | 712 | 5120 GiB |
| Tot | 34 | 2616 | 19456 GiB | |
And a list of moves to get there, including new installs