Experimental Flags

/tmp on ram

This option allows the job to mount /tmp as tmpfs (ram).

When used, the /tmp directory will be mounted as tmpfs (ram) instead of the default behavior which is writing to the disk. This can be useful to avoid disk I/O and speed up the job.

Note

If more data are written than the amount of requested memory, the job will fail with OOMKilled (Out Of Memory Killer).

method	description	examples
new	`--alphabit tmp_on_tmpfs`	`eai job new --alphabit tmp_on_tmpfs`
yaml	`alphabit.tmp_on_tmpfs:`, any	alphabit: tmp_on_tmpfs: {}

Reserved nodes only

This option allows the job to be scheduled only on reserved nodes. When used, the job will not spill out of the reserved nodes.

Usage

method	description	examples
yaml	`alphabit.reserved-nodes-only:`, list<string>	alphabit: reserved-nodes-only: - account - parent-accounts - organization

Example Context

For the next example, the following context will be used:

Organization and accounts:

organization A
  account B
    account B1
  account C
  account D

With the reserved nodes:

Node 1: Reserved for account B
Node 2: Reserved for account C
Node 3: Reserved for organization A

Possible value

alphabit.reserved-nodes-only can be a combination of the following values:

account

With this value, the account of the job must exactly match with the account of the reserved nodes.

alphabit:
  reserved-nodes-only:
  - account

Job submission with this option:

A job submitted in the account B can only be scheduled on node 1.
A job submitted in the account B1 cannot be scheduled and will fail directly.
A job submitted in the account C can only be scheduled on node 2.
A job submitted in the account D cannot be scheduled and will fail directly.

parent-accounts

With this value, the account of the job needs to match with the parent accounts only (account itself and organization excluded).

alphabit:
  reserved-nodes-only:
  - parent-accounts

Job submission with this option:

A job submitted in the account B cannot be scheduled and will fail directly.
A job submitted in the account B1 can only be scheduled on node 1.
A job submitted in the account C cannot be scheduled and will fail directly.
A job submitted in the account D cannot be scheduled and will fail directly.

organization

With this value, the job will only be scheduled on the node reserved for the organization of the job

alphabit:
  reserved-nodes-only:
  - organization

Job submission with this option:

A job submitted in the account B can only be scheduled on node 3.
A job submitted in the account B1 can only be scheduled on node 3.
A job submitted in the account C can only be scheduled on node 3.
A job submitted in the account D can only be scheduled on node 3.

Combination Example

account & parent-accounts

With these values, the account of the job needs to match with the account or the parent accounts (organization excluded).

alphabit:
  reserved-nodes-only:
  - account
  - parent-accounts

Job submission with this option:

A job submitted in the account B cannot be scheduled on node 1.
A job submitted in the account B1 can only be scheduled on node 1.
A job submitted in the account C cannot be scheduled on node 2.
A job submitted in the account D cannot be scheduled and will fail directly.

Root certificate location

This option allows to update the location where is mounted the root certificate in the job container.

By default /etc/ssl/certs/ca-certificates.crt is used. CA_CURL_BUNDLE environment variable is also set to the same value.

When this option is used, the specified location will be used to mount the root certificate provided by Toolkit. CA_CURL_BUNDLE will be also updated to the specified location.

Note

CA_CURL_BUNDLE can be overwritten by the user by using the -e/--env parameter.

method	description	examples
new	`--alphabit root_cert_path`	`eai job new --alphabit root_cert_path=/tmp/root.crt`
yaml	`alphabit.root_cert_path:`, string	alphabit: root_cert_path: /tmp/root.crt

Simulation of job preemption

This option allows to simulate a preemption of the job. When using this option, the job will be preempted the number of times specified by the interrupts parameter.

This options is divided in 2 parameters:

interrupts: Number of preemption to do on the job
interrupt-after: Number of seconds to wait before preempting the job

Note

When using this option, it makes more sense to set the job as Restartable.

method	description	examples
new	`--alphabit interrupts` `--alphabit interrupt-after`	`eai job new --alphabit interrupts=2 --alphabit interrupt-after=60`
yaml	`alphabit.interrupts:`, int `alphabit.interrupt-after:`, int	alphabit: interrupts: 2 interrupt-after: 60