Sharing Resources

Topic

Letting a resource be shared among services. This does complicate things, but there are a few compelling use cases for it.

Camera Streams

An embedded camera device (or camera in a network) represented in the same way as a robot to the concert. Each resource would be capable of running one of a library of apps. The default would be a basic image stream, others may render some processing on the embedded device side which provide modified output. This camera's image or video stream doesn't have to be locked down to a single consumer (consumer = concert service).

Software

You might have a software application on the lan which does face identification. This could potentially be a resource, but you don't want to lock this to a particular concert service. It might be a basic request/response service (like web services) but running on the lan and you want to share it to all concert services. Prime example. Access to a mongodb with a ros api wrapping it's access.

Related Topics

• Software Resources - important if we want to define resources as lan service style resources.

Current Resolution

* Workaround these problems in the rapps themselves for now. Start looking at a proper shared solution in the future.

Discussion Thread

December 3

• (Piyush) What are the options for being able to do this right now?

  • (Daniel) 1) Get rapps to workaround themselves, e.g. start up the database on the configured url if it isn't there, or just access it otherwise. Store their own counts in the database and last man leaving closes the database. Not great as it requires alot of work from the user (writer of a rapp).

  • (Daniel) 2) Get the solution configured to start these up, ugh. We are trying to avoid solution configuration, not make more.

  • (Daniel) 3) Get the scheduler to handle this 'feature' under the hood. It will be complicated, e.g. the remappings etc.

• (Piyush) 3) is best, no work for the user, but we'll need time to do that properly.

Pre-December 3

• (Daniel) Right now, the important use case for us is software resources. Refer to that for more detail.

• (Daniel) If we do go down the sharing route, the major obstacle is to work out how to handle remappings. Typically we remap every resource to suite the service. But in the case of shared resources, services are going to get into conflicts over these settings and they should be handled differently.

• (Daniel) How to define what apps are sharable? Min and Max limits of sharablility?

  • (Jack) One idea: treat shared resources as a hardware allocation problem. Each of these shared resources estimates the number of concurrent uses it can handle and advertises that many rapp instances. That number could be adjusted dynamically based on usage experience. The scheduler assigns instances as they become free, making additional requests wait when they are all busy.