Requirements

This page documents the infrastructure requirements of the OCaml open-source tooling, in an effort to ease allocation of the available resources.

Continuous Integration

• docker-base-images.

  • OCurrent orchestrator (toxis)
  • AMD64 builder (amd64)
  • ARM32 builder (arm32-1, arm32-2)
  • PPC64 builder (ppc64)

• ocaml-ci.

  • Production.
    • Web front-end and OCurrent scheduler. (toxis, but could/should be a separate, smaller machine)
    • Build fleet (toxis, laodoke, phoebe)
  • Staging. A similar environment to production, but with a smaller build fleet (e.g. web front-end, scheduler, debian build machine). (UNALLOCATED)

• ocaml-cb

  • Existing: autumn. Benchmark machine. Runs with isolated CPU cores for the benchmarks so needs to be baremetal and dedicated.
  • UNALLOCATED: An extra machine (can be a VM, shared) that runs the ocurrent orchestrator to trigger the benchmarks and host the web frontend. Suggested minimal setup: 2 cores, 8gb ram, 500mb disk, ubuntu 18.04

• www-deployment pipeline

  • Existing: none?
  • UNALLOCATED: A server that can host KVM unikernels, ideally with multiple IPv4/IPv6 addresses for automatic deployment from an ocurrent pipeline. If we can't get extra IPs an alternative could be do deploy the http instances behind an nginx frontend (or unikernel). Suggested minimal setup: bare metal, 4 cores, 16gb ram, 1tb disk, ubuntu 18.04

• opam-health-check.

  • Production. A beefy server hosting frontend/build server for check.ocamllabs.io (hipp)
  • Testing. A server half (or even a quarter) the size of the production server would be enough to test several improvements such as new versions of opam-health-check, new opam solver, opam optimizations, new releases of the compiler, custom tests for opam-repository PRs (sometimes the CI environment is not enough and requires custom tests such as for revdeps, or custom dependencies/distributions) (UNALLOCATED)

• opam-ci.

  • Web front-end and OCurrent scheduler. This would be at first a testing server. A normal size server would be enough, no need for crazy specs if the build fleet of ocaml-ci (see above) is accessible. If not, its size would be to be discussed, possibly a normal size for testing and taking what currently drives ci.ocaml.org instead. (UNALLOCATED)

• mirage-ci (opam-repository CI).

  • Production. A big server hosting frontend/build server for ci.ocaml.org (pima)

Continuous Benchmarking

• bench/caelum-513

  • Public facing operf-micro benchmarks http://bench.ocamllabs.io/

• bench2/caelum-614

  • Public facing sandmark benchmarks http://bench2.ocamllabs.io/
  • OCaml custom branch sandmark benchmarks http://bench2.ocamllabs.io:8083/
  • F* benchmarks http://bench2.ocamllabs.io:8070/

• [winter]

  • Currently staging up-to-date sandmark benchmarks http://winter.ocamllabs.io/ but you need to tunnel to it to see them.

Multicore development

• [bremusa/128.232.80.167]
  • General purpose development benchmarking when needing 20+ cores
  • General purpose multicore testing (and particularly repeated testcase running to find bugs and refine to a small testcase)
  • General purpose multicore development (particularly build and run testsuite prior to pushing PR branches)