seastar
seastar copied to clipboard
Make seastar options HUP-updateable
Currently all seastar options are immutable after seastar app starts. That's not very convenient as it takes full app restart to pick up new options if needed. Some options, however, allow live-updating because they either just one-to-one map to some simple reactor variable or because live-update can be implemented as a callable.
Seastar can read its options from ini-style seastar.conf file, so what this PR does is makes seastar re-read this file upon receiving HUP signal (*). Options should be marked as live-updateable explicitly by providing a noncopyable function on construction. When config file is re-read all those functions are called with new values arguments.
As an example the --unsafe-bypass-fsync is turned into live-updateable option.
(*) Scylla re-installs HUP handler, so it'll have to call reread_config() by hand.
Finally we have it! Thanks for caring
On Fri, Apr 14, 2023 at 10:25 AM Pavel Emelyanov @.***> wrote:
Currently all seastar options are immutable after seastar app starts. That's not very convenient as it takes full app restart to pick up new options if needed. Some options, however, allow live-updating because they either just one-to-one map to some simple reactor variable or because live-update can be implemented as a callable.
Seastar can read its options from ini-style seastar.conf file, so what this PR does is makes seastar re-read this file upon receiving HUP signal (*). Options should be marked as live-updateable explicitly by providing a noncopyable function on construction. When config file is re-read all those functions are called with new values arguments.
As an example the --unsafe-bypass-fsync is turned into live-updateable option.
(*) Scylla re-installs HUP handler, so it'll have to call reread_config() by hand.
You can view, comment on, or merge this pull request online at:
https://github.com/scylladb/seastar/pull/1615 Commit Summary
- 2994fee https://github.com/scylladb/seastar/pull/1615/commits/2994fee38b8527a2fa1406ad2673f0cf4e9d3e53 app-template: Add --config-file option
- dff39c8 https://github.com/scylladb/seastar/pull/1615/commits/dff39c8470e273d1032d658fb0f334e693b96f3f app-template,program-options: Kick config file re-read on HUP
- be588f4 https://github.com/scylladb/seastar/pull/1615/commits/be588f4860b9b0421521cf7f48871c187e68081e program_options: Introduce updateable_value<>
- 8780210 https://github.com/scylladb/seastar/pull/1615/commits/8780210ef85efc8dc051067208b3480eb3220230 reactor: Make unsafe-bypass-fsync updateable_value
File Changes
(6 files https://github.com/scylladb/seastar/pull/1615/files)
- M include/seastar/core/app-template.hh https://github.com/scylladb/seastar/pull/1615/files#diff-3e190d644dc87f6078b21e63c0a9810ed11149b254fac0ee0835e6af78fab8c7 (3)
- M include/seastar/core/reactor_config.hh https://github.com/scylladb/seastar/pull/1615/files#diff-fd0fd4159888fc76a61154ea3374f2dc4324f1a87f2bc5bee2a99378375ec7ce (2)
- M include/seastar/util/program-options.hh https://github.com/scylladb/seastar/pull/1615/files#diff-caeaa5bcacc9586a4a16ff15a03b27c68be1ebb7b9819aefb18f98213e8c6a68 (31)
- M src/core/app-template.cc https://github.com/scylladb/seastar/pull/1615/files#diff-e2dd21fb36d34d21fc9aa54ecf80b6251c831a79d22572db2b9451e06f7569af (22)
- M src/core/reactor.cc https://github.com/scylladb/seastar/pull/1615/files#diff-5e5dfd46a396d71e0d68f183d6eb0f3bb5aad37be914323b8e4fea134dafec0c (6)
- M src/util/program-options.cc https://github.com/scylladb/seastar/pull/1615/files#diff-6f4535603abb308fbf9f665e3b54f5ca9b48a77fdb84ed0b87cb29a7c9e644c5 (18)
Patch Links:
- https://github.com/scylladb/seastar/pull/1615.patch
- https://github.com/scylladb/seastar/pull/1615.diff
— Reply to this email directly, view it on GitHub https://github.com/scylladb/seastar/pull/1615, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANHUROXFHTEP3A5EB5VC5DXBGCBRANCNFSM6AAAAAAW6V7Z7Q . You are receiving this because you are subscribed to this thread.Message ID: @.***>
upd:
- make reread_config() public so that app could kick it by hand
- call updating callback when the option is "back to default"
- protect against accidental HUP re-entrance
- default --config-file to be ~/.config/seastar/seastar.conf
- fail start in case --config-file is specified, but the file is not readable for whatever reason
upd:
- handle restore-default case for nullopt defaults
upd (applied @tchaikov suggestions around tilde expansion):
- check config_file not to be empty
- abort on unset HOME early and explicitly
- .replace() tilde with raw home, w/o converting it to std::string
@denesb , merge ping
@denesb , merge ping
I'm not a seastar maintainer.
@avikivity , review ping
@avikivity , review ping
@avikivity , review ping
@avikivity , review ping
upd:
- rebased
- added sugar for reactor options cross-shard updating
- made more options live-updateable
@avikivity , your review is very much welcome
@avikivity , please review
Having Seastar be responsible for reading options was a design mistake IMO. The app should be responsible for options, and of it needs to send some to Seastar that it should do so via app_template::config. Then, the names of the parameters, the format and location of the configuration file, and responsibility for reloading are all up to the application.
So, we need to choose. Do we continue to improve option processing, or do we deprecate them in favor of moving everything to the application?
I partially agree with that and the "it needs to send some to Seastar that it should do so via app_template::config" was mostly addressed by the 8810950b92eaa7f4115eb19e3294a5c6c1af8cb9 work. The only difference is that the configuration is fed via app_template::seastar_options
, not app_template::config
. And this PR mostly touches the program_options
to make it live-updateable. Hunks to inject HUP handling and the --config-file
option are there just because that's the current way program_options
are populated.
As far as "the names of the parameters, the format and location of the configuration file, and responsibility for reloading are all up to the application" is concerned. Let's take for example fbb9fcd15a7e15c24b75f85b003723bea29d85e5. If this option was added without seastar support for the option CLI name, then all apps using seastar would need to add the option on their own, which's not very convenient. I think that it's still worth keeping the config and/or CLI parsing in seastar, but maybe isolating it even more in util so that it's fully optional.
I though to keep exposing bpo helpers, so a bpo application can continue ask Seastar to add Seastar options to the application bpo parser.
I think this is problematic, it adds a new configuration file format for the application. For ScyllaDB, it means an extra source of configuration outside scylla.yaml.
I think this is problematic, it adds a new configuration file format for the application. For ScyllaDB, it means an extra source of configuration outside scylla.yaml.
One cannot tune seastar options via scylla.yaml
even now. I do not remember the exact file names and options, but if someone needs to add seastar options to installed-and-running scylla, one needs to find SCYLLA_OPTIONS (?) variable in /etc/
I think this is problematic, it adds a new configuration file format for the application. For ScyllaDB, it means an extra source of configuration outside scylla.yaml.
One cannot tune seastar options via
scylla.yaml
even now. I do not remember the exact file names and options, but if someone needs to add seastar options to installed-and-running scylla, one needs to find SCYLLA_OPTIONS (?) variable in /etc//scylla. shell script (with variables) and put it there as a CLI option, not as .yaml/.json/.ini entry. So it's pain anyway -- either there are two config files, or the need to teach scylla.yaml to configure seastar options.
Sure, but isn't it overall nicer to have options in one place? I'm thinking of --blocked-reactor-notify-ms (which might as well be renamed).
btw, it's a little problematic since the file has to be accessed both via Seastar APIs and via standard APIs (before launch), but that's life.
Sure, but isn't it overall nicer to have options in one place?
It is, but seastar.conf is the legacy file. I don't know if anyone is using it so presumably we cannot just drop it. OTOH, following the direction of non-framework-ish options maintaining, this PR shouldn't have the part that's responsible for re-reading seastar.conf.