Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Add an option to auto-reload configuration file on change #41

Open
jerluc opened this issue Feb 2, 2021 · 1 comment
Open

Add an option to auto-reload configuration file on change #41

jerluc opened this issue Feb 2, 2021 · 1 comment
Labels
enhancement New feature or request
Milestone

Comments

@jerluc
Copy link
Member

jerluc commented Feb 2, 2021

There are some use cases in which it would make sense for tilenol to be able to auto-reload its configuration.

For example, when tilenol's configuration is mounted as a file from a ConfigMap in a Kubernetes environment, the ConfigMap may change when someone applies a new configuration via kubectl, but tilenol does not update since it only ever reads the configuration from disk on boot. Notably there are some temporary workarounds for this particular scenario, e.g. Reloader, but it might make more sense to simply add a new CLI flag, e.g. --reload, to support automatically watching for configuration file changes.

@jerluc jerluc added the enhancement New feature or request label Feb 2, 2021
@jerluc
Copy link
Member Author

jerluc commented Feb 3, 2021

Note that there are a couple of minor implementation wrinkles that would need to be addressed in order to support this new feature:

  1. Since configuration can affect which layers are accessible and the source data behind them, we will need to provide some safety mechanism around the implicit "pointer swap" that will need to occur when rehydrating layers from a freshly-reloaded configuration while concurrently servicing other in-flight requests; the simplest thing we could do is to use a multi-reader/single-writer mutex (the sync.RWMutex is probably most appropriate for this use case) to ensure that when the configuration is being applied to the running server, we at least retain memory consistency within a single request. Furthermore, since the configuration can also change the cache, this control mechanism/semaphore will need to lock readers before the caching middleware is invoked
  2. Since configuration changes may also imply that existing layers are reconfigured to return different data, we should also consider implementing the content-based hashing mechanism described in [RFC] Consider caching data per-layer rather than per-request #25 as a way to forcibly cause cache misses for subsequent requests to updated layers

@jerluc jerluc modified the milestones: v2.0.0, v1.2.0 Apr 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant