Deployment Scenarios and Testing

[salotz]

In order to design proper "process" backend abstractions it should be necessary to pin down exactly what kind of deployment strategies we want to support. Furthermore, this will actually give us a checklist of concrete kinds of tests we want to support.

There are 4 broad categories of actor deployment:

• single process, single threaded, single host :: this is what plain old python without multiprocessing (or any future deGilled threading) provides. This is the most portable, but also the least useful, since presumably the point of using an actor model is for parallel computing.

• single process, multi-threaded :: this would be using OS provided thread scheduling for parallelism. Not really possible with current python so we'll leave it out of the other ones.

• multi-process, single host :: i.e. not-distributed. We only need to have a python environment on a single computing host. Uses OS IPC for communication.

• multiprocess, multiple hosts :: i.e. distributed. Requires some method of deployment of python programs to hosts across a network. Uses network protocols for communication.

Deployment options:

First is what I call the "herd of unixen" of which there are multiple strategies for ranging from completely ad-hoc to completely software defined, in that order roughly:

• "ponytail cowboy" style :: scp, ssh, perl, bash, and other manual sysadmin ways of replicating environments on other machines.

• configuration management tool :: ansible, puppet, fabric, etc. which pretend to offer idempotency etc.

• functional package managers with Ops :: Nix and Guix with NixOps etc.

• linux containers :: docker, LXC, Rancher, etc.

• VMs on Hypervisors :: Xen, VirtualBox, etc.

Of these the most reasonable are CM tools, functional package managers, and linux containers all having different tradeoffs for different scenarios. For initial testing purposes containers will probably be the easiest here since we don't actually need to set up VPSs or an RPi cluster.

Another non-unix approach is the use of unikernels like UniK, OSv, potentially Genode. IMO these have all of the benefits of containers with better encapsulation, smaller footprints, shorter startup times, and the potential to be "on the metal" and not have to compete for scheduling. The drawback is that they are underdeveloped in terms of tooling compared to something like Docker.

Of special interest is Genode, which actually can go beyond the unikernel use case that I won't detail here as it is very much a futuristic thing and a lot of the standard unix ways of looking at "processes" breaks down.

Another novel (and very appealing) scenario is that implemented in the mitogen project which can self-replicate python programs to any (unix) machine with a sufficient python version installed. Biggest drawback here is that I don't think you can do any FFI or rely on any subprocess calls to the system (without also using one of the above tools).

TODO: put links in

[goodboy]

Hmm, linking this to #149 which is basically a first attempt at this.

@guilledk just fyi.

[goodboy]

Some projects that might be helpful down the road @guilledk :

• https://containernet.github.io/

  Containernet is a fork of the famous Mininet network emulator and allows to use Docker containers as hosts in emulated network topologies. This enables interesting functionalities to build networking/cloud emulators and testbeds. One example for this is the NFV multi-PoP infrastructure emulator which was created by the SONATA-NFV project and is now part of the OpenSource MANO (OSM) project.

• toxyproxy: https://github.com/Shopify/toxiproxy

• wirefilter: https://manpages.ubuntu.com/manpages/trusty/man1/wirefilter.1.html