Rust Railroad Cloud Infrastructure Project

Or simply... Railroad :)

Please Note: This project is in alpha, likely unstable, a hot mess, and will stay that way until a rewrite is called.

This is a learning project for me (the author, Jonathan de Jong), to try and understand how to make cloud infrastructure in rust, in this day and age, in a manner that is both safe and extendable, with multiple levels of hierarchy.

This doesn't mean I don't accept PRs, suggestions, or improvements, but that I don't make effort to exhaustively make and keep this project stable until the rewrite is called, after which I apply all my knowledge and suggestions to make version 1.

This project follows semantic versioning, with the major exception being for major version 0, in which there are no guarantees for stability in-between minor or patch versions.

Components and Terminology

This project uses train-related and derived terminology, to keep in the motif and idea of a "railway" cloud;

Note: These names and definitions are not set in stone.

• "Train", the node-level daemon/manager, manages extensions ("train carriages") on the same daemon, and is the node-local endpoint.

• "Carriages", the components that hang under a "Train", these manage the actual resources running on the machine (e.g. VMs, Containers, etc.), communicating with the Train to keep it up-to-date with state, and receiving imperative commands on abstract objects to interpret.

• "Railyard", a cluster manager for multiple Trains, possibly also performs orchestration, resource failover, inter-train networking, and other tasks.

• "Railway", a top-level/global cluster manager, possibly manages policy, federated networking, and other such tasks.

Every one of these components receive a CLI, possibly also an ncurses-based interface, providing a web GUI is out of the scope of this project (for now).

Mission

I (the author) believe in an open internet for everyone, unfortunately, this isn't true of cloud-like compute environments; managed systems which are able to aggregate and abstract itself over both hetrogenous and fine-tuned components. These resources have mostly either been locked behind doors of commercial entities, or been inefficiently or insufficiently provided by vendors/groups for local entities.

This project aims to create an open-source robust cloud for everyone, built upon by anyone, for any workload.

Function over Form, but optionally Form if it doesn't compromise Function.

About the Alpha stage

I personally have difficulty keeping my focus on one project, so I don't make promises to finish this any time soon, or to make it a serious endeavour until I think it's ready for it.

Right now (Oct 2020) I am definitely both not proficient in rust, and/or what the "best infrastructure" looks like for this kind of management, and how to make it sufficiently future-proof.

So the Alpha stage of this project is poking at solutions, trying out configurations, crates, best practices, and studying them, before making the final call.

"A delayed game is eventually good, but a rushed game is forever bad."

(Shigeru Miyamoto)

I believe the same applies to system architecture, while there is a fine balance between over-studying it and knowingly not knowing something, I believe I'm currently in the latter camp, thus the Alpha period.

Licensed under the EUPL, version 1.2