Feat: Discussion about Jade Service Runner Behavior

[zcstarr]

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

1. With config? what are the params we should use?
2. Is there a list of support services or registry?
3. local is the aim but what about mobile support?
4. x
5. Who launches the service the dApp wants to run?
6. In an ideal world do we allow the dApp dev to specify installation instructions?
7. 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)?
8. This should be easy enough to do/track with service runner
9. The service runner daemon should take care of rebooting
10. Hopefully using the open-rpc generator for the services its requesting generates easy to use clients that can connect to the services requested easily.
11. 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]

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 etclabscore/jade#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]

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]

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]

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]

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]

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

[zcstarr]

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