Feat: Discussion about Jade Service Runner multiple version shared resources
Opened this issue · 2 comments
Jade Service Runner should support multiple version resource reuse. The issue is that many types of services/api/programs might need to share the same resources or sets of resources between versions. Currently there is no way to accomplish this, outside of a hard reset for services. A tangential problem that we encounter is interdependent services. I'm not saying we should support this, but it is a topic for discussion. So I'll try and address the concerns below.
Problem 1:
We have a resource environment called a service. Within that environment, you can have many different versions. The versions might need to share resources, how do you enable the versions to share. How do you also restrict sharing to some but not all versions/env?
Problem 2:
Services are their own environment. How do you depict a dependency between services?
Examples
Real Life: Multi-geth 1.9.2 is different than 1.9.0 , but would like to share the data dir.
Real Life: Jade Signer relies on the same data dir as multi-geth x.x.x
Describe the solution you'd like
I believe a solution to Problem 1, might take the shape of dynamic shared resource allocation where possible. The following I believe might hold true.
- Define at the top of a service config a set of shared resource descriptions/sub_paths for resource
- Define a valid version interval for that service version to be a part of a shared config
- Use service runner to resolve and define paths within the service manifest file such that
service runner can have virtual paths that map versions to directories. - If a service is cleaned up, check to see if any other versions of that service are relying on the shared asset before removing all references to the shared asset.
Cavet
The above approach makes a few assumptions.
- That the resource under question is available to be remapped to a autogenerated shared resource directory.
- The directory is not generated at some point during runtime and needs to then be dynamically added to a shared config. It assumes the root path is known
The problems I see with the above is that it gets kind of messy, resolving paths for shared resources. If you could restrict the class of shared resources to being arguments for services, this would make things easier. However, I don't believe that it's the best experience for a developer, due to the need to potentially share resources due to dynamic generation of said resources.
Curious what people think. Below is a gist of proposed schema changes to make the above work. It's all very tenative and not super high priority relative to the other stuff, but worth collecting our thoughts for later.
https://gist.github.com/zcstarr/00755ac35fc6649d76c40c5bdd3ce0a9
One potential implementation - idea is to support sym link + hard copy. It's worth looking into the implications.
adding a note, this will also need to have the intersection of environment + version for the mapping of what's supported as a shared resource.