Frontend overprovisioning multicore glideins
The Frontend logic for calculating the number of glideins to requests assumes one job per glidein;
which may not be true for multicore glideins.
This results in requesting too many glideins, especially when there are only a few matching jobs in the queue.
#3 Updated by Parag Mhashilkar over 5 years ago
Talked to Igor about this issue as this affects/needs coordination with the operations.
- Entry should be configured with GLIDEIN_CPUS and it should be advertised as part of the glidefactory classad. GLIDEIN_CPUS can be a numeric value or auto. This scheme works well with numeric value but not auto. In case of auto, there is no good way of identifying the info unless we assume a number.
- Frontend uses GLIDEIN_CPUS from the glidefactory classad. If not available, or set to AUTO assumes 1.
- Frontend looks for RequestCpus in the jobs classad to determine the cpus requested. If not specified, assumes 1.
- When frontend tries to figure out the sites for every job, we request glideins at sites that provide N+ cpus only.
- Frontend tries to figure best number of glideins it should request per entry in this case and makes the request accordingly.
- There is no costing and all the sites are treated equal.