It would be great to get this into kube as an example to rule them all. One possibility is simply to stick out the pacman metaphor forever, and expand it, Per conv w / @wattsteve @font
- new database backends,
- have it use kube user facing features like liveness and readiness
....etc...
I'll create a feature list here and expand over time. Some starters:
- Spark or Flink integration: Analyze performance of various pacman graph algorithms on average (bellman ford/bfs/dfs). Im sure there are research papers and stuff on ideal pacman algorithms as its a generalizable problem.
- Bots so that it scales to N data generators https://github.com/telecoda/go-man-app might be a start to fork. Allow users to enter algorithm as a lua plugin into the browser so they can build there own pacman bot armys.
- Exemplify Liveness + Readiness by embedding a timebomb into the app which causes it to die. This would eventually trip kubelets to restart the container. Allow users to update the timebomb to see analytic event throughput die and then recover
- Run from source so no external images other then the baseline golang ones in upstream kube ci are used , or for example
FROM golang:latest which might be in the CI images already. Gaurantees upstream compatibility.
- Retain the federation capacity, allow people to enter N credentials cloud vendors and deploy it across all N clusters. Get vendor buy in on this so that AWS, azure, and so on support the interface for users to submit the clouds they care about.
It would be great to get this into kube as an example to rule them all. One possibility is simply to stick out the pacman metaphor forever, and expand it, Per conv w / @wattsteve @font
....etc...
I'll create a feature list here and expand over time. Some starters:
FROM golang:latestwhich might be in the CI images already. Gaurantees upstream compatibility.