zcstarr commented 5 years ago

Creating this issue to start a conversation about what the service runner should be solving, so we can scope the initial version of the project properly, while keeping the end developer in mind. The aim is to use this document to help write the readme and generate architecture docs, and figure out what v0 needs to do.

Jade Service Runner

Abstract high level goals

Jade Service Runner is a utility that makes it easy for dApp developers to allow end users to run and connect to their own services. In order to achieve this the service runner should make it easy to complete the following tasks. Either by hand or by code automation from the dApp.

User potential high level abstract goal

find a service
download the service
install service
support dApp configuration for a service ( user doesn't have to be too technical)
run or connect to an existing dApp configuration for a service
maintain service liveness
dApp developer potential high level abstract goals
request access to open-rpc supported services
use whatever shared open-rpc services are configured properly for the dapp
specify service requirements
provide easy to understand setup for users without heavy lifting
have IDE useable discovery of RPC functionality (types)
use generic or specific open-rpc services i.e. support mgeth ∩ geth ∩ parity vs parity ∪ mgeth ∪ geth
easy to configure support for mobile(light client) or remote services
Where are we headed??

Let's try to imagine what an dApp developer would have to do to launch a shopping dApp.

Assumed Developer Concerns
1. Pick a or many services + version + env + args (limit security access) //dApps
2. Figure out where to get a service client
3. Decide how to run service (assume local/remote - (ethernode)/embed)
4. Assuming local for what follows
5. Decide to launch service if its not running or assume its running
6. If its not running and doesn't exist suggestion installation to a user
7. Decide how to figure out its running the right version + env (config) //think multi-geth/gorli vs main
8. Verify the service is up once its running // liveness (rpc.discover)
9. Suggest how to reboot the service if its crashed or gone missing
10. Develop the rest of the app
11. Security concerns
  Jade Service Runner Addresses
12. With config? what are the params we should use?
13. Is there a list of support services or registry?
14. local is the aim but what about mobile support?
15. x
16. Who launches the service the dApp wants to run?
17. In an ideal world do we allow the dApp dev to specify installation instructions?
18. This is tricky, becaue forks of clients exist and if services are "non-blessed" how do we know what version ( Does this require a registry)?
19. This should be easy enough to do/track with service runner
20. The service runner daemon should take care of rebooting
21. Hopefully using the open-rpc generator for the services its requesting generates easy to use clients that can connect to the services requested easily.
22. Running many services and different versions manifest file has been suggested for specifying open-rpc files to use for generating clients, as well as potentially generating a generic

zcstarr commented 5 years ago

I wrote this quickly to just put together a list of the concerns so we can keep these things in mind. I avoided talking implementation specifics. I wanted to see if these problems meshed with the ideas we all have in the brain. I think what I'll end up doing as we gain consensus or question, is then add a section that talks more implementation/proposals for executing the above. It's a product slant first.

I think impl wise we can probably have the service runner as the open-rpc supported entity, and can use https://github.com/etclabscore/jade/pull/18 , maybe refiling the PR in this repo to start iterating on what the exact spec should be.

Let me know what you think or what should be change or if this should be moved into a PR if that's easier to suggests edits etc...

shanejonas commented 5 years ago

This is a great summary of everyones thoughts so far on this. 👍

Going to read through a couple times, gather some thoughts around it overnight.

zcstarr commented 5 years ago

Initial open-rpc starting gist for some our thinking post offline meeting

{
    "info": {
        "title": "something",
        "version": "44"
    },
    "methods": [
        {
            "name": "installService",
            "params": [
                {
                    "name": "serviceName",
                    "schema": {
                        "type":"string"
                    }
                },  
                {
                    "name": "version",
                    "schema": {
                        "type":"string"
                    }
                }
            ],
            "result":{
                "name": "installSuccess",
                "schema": {
                    "type": "boolean"
                }
            }
        },
        {
            "name": "configService",
            "result": {
                "name": "configurationSuccess",
                "schema": {
                    "type": "boolean"
                }
            },
            "params": [
            {
                "schema": {
                    "type": "string"
                },
                "name": "serviceName"
            },
            {
                "schema": {
                    "type": "string"
                },
                "name": "environment"
            }
        ]
}
],
"openrpc": "1.0.0-rc0"
}

https://gist.github.com/zcstarr/961f861dcc711a647297c4ca1c945b14

zcstarr commented 5 years ago

Service Runner Tenative V0 Scope

ServiceRunner is a standalone service manager, that supports starting, stopping, and installing a limited range of OpenRPC projects. This range can be extended via configuration file. The service runner runs services by responding to JSONRPC request to start/stop/ or gain access to services. The initial target is multi-geth + jade-signer.

Potential Service Runner Commands

 servicerunner —extends config.yml
// This command allows the user to extend the pre existing services configuration

ServiceRunner Extended Configuration Tenative Example 

 {
  ethclassic: {  /* serviceName */
      download: {  /* where to get service */
        osx: "https://some.binaryfile.location"
        windows: "https://some.binaryfile.location"
        linux: "https://some.binaryfile.location"     
      },
      start: “command” , /* commands to execute the process*/      
      stop : “command”, /* commands to stop the process */
      teardown: “command” /* commands to teardown the process */
      env: { /*specifies what supported run time environments per service*/     
          mainnet: { /*environment name and specific config */
        args: []
            start,
            stop,
            teardown,
          },
          gorli: { . /*environment name and specific config */
         args:[]
          }        
      }
   }
}

BelfordZ commented 5 years ago

for env - can we make it an array of object, where the object has the property name?

Also, can you turn this into a JSON schema?

zcstarr commented 5 years ago

done and done, took a stab at a slight revision/rewrite in json schema https://gist.github.com/zcstarr/415265efae3662c481c488e0b7bab083

zcstarr commented 5 years ago

JSON Schema response for starting a service https://gist.github.com/zcstarr/eecc9d495b7e0e19a65a5899a4c6e379

etclabscore / jade-service-runner

Feat: Discussion about Jade Service Runner Behavior #2

Jade Service Runner

Abstract high level goals

User potential high level abstract goal

dApp developer potential high level abstract goals

Where are we headed??

Assumed Developer Concerns