Decide Runtime Targets

[abernix]

We want the Router to be able to run "Anywhere" but we need to start with a practical list of targets that we can ship and be cognizant of the constraints that some "nice to haves" would put on us.

Candidates

As a conversation starter, I suggest we have only Tier 1 target architectures as candidates. Lifting that list from the linked page, it's:

target	notes
aarch64-unknown-linux-gnu	ARM64 Linux (kernel 4.2, glibc 2.17+) [^missing-stack-probes]
i686-pc-windows-gnu	32-bit MinGW (Windows 7+)
i686-pc-windows-msvc	32-bit MSVC (Windows 7+)
i686-unknown-linux-gnu	32-bit Linux (kernel 2.6.32+, glibc 2.11+)
x86_64-apple-darwin	64-bit macOS (10.7+, Lion+)
x86_64-pc-windows-gnu	64-bit MinGW (Windows 7+)
x86_64-pc-windows-msvc	64-bit MSVC (Windows 7+)
x86_64-unknown-linux-gnu	64-bit Linux (kernel 2.6.32+, glibc 2.11+)

Note that this list does not include aarch64-unknown-linux-musl. That omission doesn't by itself preclude us from running on Alpine, though we are further constrained in this regard by our dependence on V8 for the query planner. This is only intended to be a constraint until the point that we can re-write the query planner in Rust natively, or until the rusty-v8 project can run more easily on MUSL. See this issue. It's surmountable, but it's probably more work than it's worth for experimental phases.

In Scope

TBD

Out of Scope

TBD

[abernix]

strawdog: let's not bother trying to support 32-bit.

other strawdogs?

[abernix]

The very general desire is that we be able to run on Kubernetes and AWS-Lambda-like environments, but that's of course caught up in the implementation details of the Docker images that are running within it and the binary that we're trying to run on it!

Kubernetes seems pretty well understood, but we should try to identify the technical requirements of running on AWS Lambda!

[savnik]

Kubernetes seems pretty well understood, but we should try to identify the technical requirements of running on AWS Lambda!

I think supporting the "cheaper" lambda architecture for ARM is preferred as the router will spend most of it's time waiting for other services to respond rather than doing anything computational heavy.

[hobbsh]

Any idea what the roadmap looks like for this? It's a huge blocker for us and I'm sure a lot of others for running the router locally (natively) on M1 Mac.

[abernix]

I'm going to close this issue, which was originally meant to track which architectures we wanted to support. If you're looking to track the ARM support stuff, then I'd recommend following #1192.