Spin Factors SIP #2518
Spin Factors SIP #2518
Conversation
| ## Implementation Details | ||
|
|
||
| Based on initial prototyping, the following Rust types represent the starting | ||
| point for `spin-factors` (simplified from the actual code for clarity): |
There was a problem hiding this comment.
simplified from the actual code for clarity
The rest of the owl: https://github.com/fermyon/spin/pull/2519/files#diff-deb13d726ac7a552e420923432af8ef603ea90b5f281de344c7a797c6b568ce3R10
| - Depending on subjective evaluation at this point, possibly merge | ||
| `spin-core` and `spin-factors`. | ||
|
|
||
| ## Implementation Details |
There was a problem hiding this comment.
@lann how will factors receive runtime config information that is not part of a factor's runtime config but still applies to it's set up. Specifically, how should state_dir and log_dir be passed which are now set in RuntimeConfigOpts alongside provider information.
There was a problem hiding this comment.
My current hypothesis is that they should be handled outside of the factors system and used to configure individual factors as needed.
state_dir will be used to build default paths for a few factors in spin up, but isn't going to be applicable to every runtime, so I think it will be up to the runtime to parse state_dir out of the runtime config and derive e.g. "default KV store path" from that to configure the KeyValueFactor.
Signed-off-by: Lann Martin <[email protected]>
Rendered