shotover/shotover-proxy

per transform webserver runtime configuration

Opened this issue · 0 comments

Currently shotover supports some runtime configuration via a built in webserver.
We currently have 1 webserver for general overall configuration and a separate webserver for tee transform configuration.
But this doesnt really scale, imagine if every transform was starting up its own webserver.

I propose we extend our general config webserver to also take configuration for any transforms that require runtime configuration:

  • We should add a /runtime_config route to the general webserver, it will be handled as:
    • GET - return the full list of runtime key/values in JSON (formatted for human readability)
{
   "transforms": {
       "the tee": {
         { "key": "result-source", "value": "tee-chain", "default_value": "tee-chain" }
         { "key": "another key", "value": "a new value", "default_value": "the default value" }
       }
   }
}
  • We should add a /runtime_config/transforms/name/key route to the general webserver, it will be handled as:
    • PUT - store the request body as the path
    • GET - return the contents as the response body.

The transform names are as designed in #337 "User configured names"
This is not yet implemented, so adding unique transform names is a prereq.

In order to give transforms control over validation of the key/values we should add the following to TransformConfig:

struct TransformRuntimeConfig {
  key: String,
  default_value: String,
  value_validation:  ValueValidation,
}

enum ValueValidation {
   Integer { min: i64, max: i64 }
   ValidStrings(Vec<String>)
   Any,
}

trait TransformConfig {
  fn runtime_config(&self) -> Vec<TransformRuntimeConfig>` {
     // by default transforms have no runtime config
     vec!()
  }
}

There is no pressing need for this cleanup but I had the ideas bouncing around my head this morning so I figured I would write them down.