Support hot reloading of configuration #67
Comments
|
I don't think this should be closed, because it is about the more user facing version of hot roloading configs. One that does not require However, I don't think this should be an M0 milestone. Work on dev tooling team can start just fine without this support. So I'm marking this as M1 instead now. @jarupatj please comment on this if you disagree with that for some reason. |
|
Solving this #189 will help here. |
|
Should we support hot reloading at all? Once runtime is bootstrapped, should we allow modifications to it? Moving to M2 for now so we can discuss more. |
|
Modified this issue to cove hot reloading of the configuration file. This will clear duplicate issues, which will all be tracked here. |
aaronburtle
changed the title
|
Would be great to have a switch on the CLI, something like --watch that will automatically reload the configuration file (and thus re-generate the in-memory schema) whenever the file is changed. Something like https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-watch That would greatly improve development velocity. |
|
In order to set the LogLevel based on the mode in the runtimeconfig we need to use a configuration provider that can reload the configuration after updating the Loglevel. More information can be found here: https://learn.microsoft.com/en-us/dotnet/core/extensions/logging?tabs=command-line |
|
Moved to April, waiting on new configuration resolver. |
|
Form the GraphQL side you need to implement an ITypeModule ... this will manage the phase out of schemas... Here you can see an example. The TypeModule is registered with the schema. |
## Why make this change? Related to, covering the runtime section of the config only #67 Because we are not able to make easy use of the `IOptionsMonitor` which would have allowed for the updating of individual sections of the config automatically (ie: just refreshing the `runtime options`), we monitor and reload the entire file. However, we currently do not have support for reloading the sections outside of the `Runtime` section of the config. Because of this, we will not document and announce this feature until the other sections can be safely reloaded. Additionally, certain options are used to configure services at startup, and despite refreshing the `RuntimeConfig`, those services will still be configured with the values from initialization on startup. This means adding a mechanism for refreshing those services to make use of the updated options after a Hot Reload, and that work will come in a future PR. ## What is this change? Adds a config file watcher during startup which will monitor for any file changes to the config and then trigger an update event in the case that the file is changed. We instantiate the config file watcher when the runtime provider is first asked to get a config. We then register a method owned by the runtime config provider that will be called back to in the case that we wish to hot reload. However, we only do this for when we start the service in local development. So that means when we are `not` late configured, and we are in a Host Mode of Development on startup. In other cases we do not watch the config file for changes, and do not make this callback in the case that the config file does change. To get the location of the file that we are going to watch we use the config loader's file system and stored data regarding the config file. ## How was this tested? Unit testing was added to verify correct hot reloading of the runtime options that we intend to have changing. ## Sample Request(s) Any valid request after the change ought to work. --------- Co-authored-by: Sean Leonard <sean.leonard@microsoft.com>
## Why make this change? This is related to the following Hot Reload PR #1726 and this issue #67 It adds a design doc to get feedback and iterate on how to implement the Hot Reloading feature. Hot Reloading will be on going work as all of the needed features to support it entirely are added. ## What is this change? Adds the design doc and a basic diagram for the Hot Reload feature. --------- Co-authored-by: Aniruddh Munde <anmunde@microsoft.com>
|
hot-reload property in config? |
|
I have created a number of sub-tasks to help track the progress on Hot Reload. Currently, we are refreshing the To facilitate extending Hot Reload in the future, a refactor of the as well as some changes to make hot reload work with the new multi config code Additionally, one of the key features we want support for hot reloading is reloading of the log-level, and so this property is being added to the config and we have a task to track being able to hot reload this property in both dev and production mode Additionally, there are some tasks for updating those settings which depend on the config only at startup, such as the OpenApiDoc and Auth settings |
|
Moving this + hot reload related tasks to post GA -> tracking via 1.2rc milestone. |
seantleonard
added
the
🔥Hot Reload
|
The top-level task tracking hot reload can remain in backlog as we address sub-tasks. Ideally a sprint's tracked work items should be resolvable. This task has so many pre-reqs , we need to resolve those first. |
Allow specifiying something like a
--watchto make the runtime watch the provided configs and reload when they change.Relevant comment from @jarupatj in #50:
#892
Tasks
The text was updated successfully, but these errors were encountered: