Now we can access pre-compiled binaries with user applications with the very same command line tool the rest of NAML uses.
The more I pulled the samples out to naml-examples the more I realized the CLI tool and the primitives built in (in addition to the Deployable() interface of course) were the bulk of the work.
This PR will allow the following workflows.
Given two users (alice and emma) each with a set of applications. The naml runtime can use them both with Kubernetes.
.
├── alice
│ ├── app.go
│ ├── Makefile
│ └── naml
└── emma
├── app.go
├── Makefile
└── naml
The user experience would look something like this.
naml -f alice/naml -f emma/naml list # This will list the aggregate of both alice and emmas applications
./alice/naml # This is the same program but only with alice's applications
./emma/naml # This is the same program but only with emma's appications
I still have at least another commit or two to refactor the child processes and harden the RPC - but this is working prototype code with bad names
Now we can access pre-compiled binaries with user applications with the very same command line tool the rest of NAML uses.
The more I pulled the samples out to naml-examples the more I realized the CLI tool and the primitives built in (in addition to the
Deployable()interface of course) were the bulk of the work.This PR will allow the following workflows.
Given two users (
aliceandemma) each with a set of applications. The naml runtime can use them both with Kubernetes.The user experience would look something like this.
I still have at least another commit or two to refactor the child processes and harden the RPC - but this is working prototype code with bad names