Optimal runtime constraints API » History » Version 1
Tom Clegg, 07/21/2023 10:59 PM
| 1 | 1 | Tom Clegg | h1. Optimal runtime constraints API |
|---|---|---|---|
| 2 | |||
| 3 | h3. Background |
||
| 4 | |||
| 5 | In some circumstances (e.g., development phase) the RAM, CPU, and scratch space requested in runtime_constraints express the _minimum_ resources needed. The user would prefer to give the container the maximum RAM, CPU, etc. that can be had for the same price as the stated requirements. |
||
| 6 | |||
| 7 | Even though the list of instance types is available via config API, it's not practical for a client to determine the maximum resource_constraints achievable by a given instance type. (For example, the extra memory reserved for local keepstore and other overhead depends on the instance config.) |
||
| 8 | |||
| 9 | h3. Proposed API |
||
| 10 | |||
| 11 | <pre> |
||
| 12 | POST /arvados/v1/container_requests |
||
| 13 | |||
| 14 | { |
||
| 15 | "maximize_runtime_constraints": true, |
||
| 16 | "container_request": { |
||
| 17 | "runtime_constraints": { |
||
| 18 | "ram": 12345678, |
||
| 19 | "vcpus": 1, |
||
| 20 | "API": true |
||
| 21 | }, |
||
| 22 | ... |
||
| 23 | } |
||
| 24 | } |
||
| 25 | </pre> |
||
| 26 | |||
| 27 | The resulting container request's runtime_constraints field may have higher numbers for "ram" and "vcpus", but not so high that they will increase the cost of the container. |
||
| 28 | |||
| 29 | The @maximize_runtime_constraints@ flag can also be used on an update request (@PATCH /arvados/v1/container_requests/$uuid@). |
||
| 30 | |||
| 31 | h3. Usage |
||
| 32 | |||
| 33 | If the client doesn't necessarily want to use the maximum possible RAM, but wants to know what the maximum RAM is, it can create a "draft" container request (priority=0) to find the maximum figures, then update it with the desired figures (obviously, without setting the @maximize_runtime_constraints@ flag). |
||
| 34 | |||
| 35 | h3. Implementation |
||
| 36 | |||
| 37 | The feature should be implemented in arvados-controller, so it can share "choose instance type" code with arvados-dispatch-cloud. |
||
| 38 | |||
| 39 | Currently the "choose instance type" code starts with @runtime_constraints@ and computes the required instance type specs. Memory overhead depends on VCPUs (because LocalKeepBlobBuffersPerVCPU) so there will be cases where we can't use all of the chosen instance's cores. Something like this: |
||
| 40 | |||
| 41 | |requested VCPUs |requested RAM GB |instance VCPUs |instance RAM GB |maximum VCPUs |maximum RAM GB | |
||
| 42 | |32 |180 |64 |200 |48 |180 | |
||
| 43 | |32 |160 |64 |200 |64 |175 | |
||
| 44 | |||
| 45 | It is possible to have multiple instance types available at the same price. This feature should narrow this down to one choice by maximizing vcpus first, then memory. (This also simplifies the competition between RAM and VCPUs in that, if we maximize RAM first, @LocalKeepBlobBuffersPerVCPU > 0@ would prevent us from ever using spare VCPUs.) |