More efficient offers handling

[mlowicki]

With offers (order matters):

• O1{mem: 100}
• O2{mem: 1}

and jobs:

• J1{mem: 1}
• J2{mem: 100}

only 1st offer will be accepted (J1 will use it) but if O1 would be used for J2 and O2 for J1 then both can be accepted and two jobs would be running instead of only one.

[pradykaushik]

This translates to a fragmentation problem. It can potentially be solved by scoring each offer using the dot product between task requirements and offer resources (taking inspiration from Robert Grandl et. al. Multi-resource packing for cluster schedulers and Netflix's Fenzo Scheduler). The goal would be to choose the offer that would have the least residue of resource (across multiple dimensions).

This can be translated to picking the offer with the least dot product with the Job.

For the given example (assuming two offers with the same available CPU),
O1 {mem: 100, cpu: 1}
O2 {mem: 1, cpu: 1}
J1 {mem: 1, cpu: 1}
J2 {mem: 100, cpu: 1}

For Job J1
J1 . O1 = {1 * 100} + {1 * 1} = 101
J1 . O2 = {1 * 1} + {1 * 1} = 2

Offer selection for J1 - O2 would be selected as it best aligns with J1.
Remaining resources in offers is as shown below,
O1 {mem: 100, cpu: 1}
O2 {mem: 0, cpu: 0}

For Job J2
O2 does not satisfy the memory requirements and hence there is only one offer remaining i.e O1.