Klaus Ma

**Motivation** Currently, it usually use MutexPtr to lock the whole object, which is overead to the Flame. It's better to use `Arc` for object, and use `MutexPtr` for its member...

**Motivation** For `flmexec` application, it's better to support running any linux command; it should take task's input as command line. For example, the command in flame-conf.yaml should be `/bin/sh -c`,...

Currently, `supervisord` is used in Flame CI; it's better to replace it with minikube to align with dev environment, and minikube is more close to the real kubernetes environment.

Currently, we have a blog to demonstrate the Rust Client. It's better to provide more document on how to use Rust Client.

**Motivation** Currently, flame dependent on flame-conf.yaml to provide the configuration of application which is hard to manage. In this proposal, we'd like to consider application as an object in Flame.

Add distributed example of pytorch for Flame.

Currently, Flame support two gRPC apis: Frontend for client api, and Backend for fem api. Usually, the cluster admin need more api for cluster operation, e.g. list executors.

It's better to build a PyTorch example to demonstrate Flame's features.