Optimal runtime constraints API¶

Background¶

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.

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.)

Proposed API¶

POST /arvados/v1/container_requests

{
 "maximize_runtime_constraints": true,
 "container_request": {
  "runtime_constraints": {
   "ram": 12345678,
   "vcpus": 1,
   "API": true
  },
  ...
 }
}

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.

The maximize_runtime_constraints flag can also be used on an update request (PATCH /arvados/v1/container_requests/$uuid).

Usage¶

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).

Implementation¶

The feature should be implemented in arvados-controller, so it can share "choose instance type" code with arvados-dispatch-cloud.

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:

requested VCPUs	requested RAM GB	instance VCPUs	instance RAM GB	maximum VCPUs	maximum RAM GB
32	180	64	200	48	180
32	160	64	200	64	175

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.)