Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Specify config to never change during the lifetime of the component. #21

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

badeend
Copy link

@badeend badeend commented Oct 6, 2024

Currently, the spec does not specify whether config values are allowed to change during the lifetime of the component.
I'd suggest: No. 🙂 Because: simpler semantics & API design.

This is in line with wasi-cli's environment variables: https://github.com/WebAssembly/wasi-cli/blob/main/wit/environment.wit

In my personal experience, it typically doesn't make much sense to do it any other way.

  • For short-lived (e.g. instance-per-request) components there's practically no difference between having them be static or not.
  • For long running applications, by far the simplest and most common way of handling config changes is simply restarting the entire application. Even high-availability software such as nginx don't bother with hot reloading.

@thomastaylor312
Copy link
Collaborator

thomastaylor312 commented Oct 7, 2024

This is an interesting discussion for sure! So I completely agree that for short lived components, this is a good rule to have. For longer running ones, many of the people we discussed this with initially actually really liked the possibility of the config hot reloading. It is difficult because there are shades here. There might be some top level config (or secrets) that you set once at the beginning of the process (like TLS certs or the like), but something like an upstream URL or redirect would be totally fine/easy to pull from config and use that instead in a dynamically updated way. For context, wasmCloud implemented it to be dynamically updated, but we can change that depending on consensus

Curious what @devigned has to say here as well

@badeend
Copy link
Author

badeend commented Oct 7, 2024

many of the people we discussed this with initially actually really liked the possibility of the config hot reloading

For extra context, are you able to share some of these use-cases?

@badeend
Copy link
Author

badeend commented Oct 7, 2024

Aside: For proper hot reloading support, wouldn't there also need to be some kind of mechanism to get notified of config changes?

Maybe, an interface like this would be more fitting to explicitly model the "changes over time" aspect?

interface store {
  type config-map = list<tuple<string, string>>;

  initial: func() -> config-map; // The config values at startup. Never changes. Effectively a "value import" which the component-model doesn't support (yet).
  current: func() -> stream<config-map>; // Get a stream that is automatically updated with the latest config values.
}

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants