How important is it to support runtime configuration change?

[hkupty]

Penna supports runtime configuration change at the moment. This means that, if you have access to the the ConfigManager, you can, during runtime, change a certain logger's (or a hierarchy of loggers) level.

However, if people feel like this is not important (i.e. it is cheap enough to update a config and restart the application), then removing this feature can greatly simplify the code.

Although I'm inclined to keep the feature, I'd like to hear what people think about it before making stronger commitments.

The implications of keeping the feature are:

• penna-yaml-config would need to support file watch (i.e. if penna's configuration is stored as a ConfigMap in kubernetes, they'd be automatically propagated upon update);
• The internal replace/update API would need to be reworked/stabilized (most likely a hard replace instead of an update);
• Given the API is shared between dev and core, maybe it should provide the default implementation which, if explicitly imported, could provide the runtime capabilities to manage the log levels, easing the burden on dev.

The implications of removing the feature are:

• The storage and the logger are going to be much simpler in code as there's no runtime config change.

[desiderantes]

Would say keep it because it's very common to have to change logger levels in something like a Spring App with Actuator (for example, Spring Boot Admin offers a nice gui to do that), and also to do things like on error threshold >= value, change log level for package.

[ggunterberg]

I don't care that i need to restart to apply, and if it improves the code base maintainability or performance or anything I prefer this lib to not support runtime changes.

The only thing that matters to me is that i can programatically setup the configuration during the application startup (and not whenever else) from a shared module in my monorepo.

Plus, the only configuration that matter to me is the logging level of certain packages, I don't see myself changing any other config as long as the defaults are good, my use case is simply a lot of services running in a k8s cluster, updating versions is trivial when using ci/cd tools.

I should be able to use my own externalized configuration lib if I need more flexibility, but still using it at application startup only.

[hkupty]

Thanks for the feedback!

penna-api enables you to configure Penna programmatically and you can do so at any time it is convenient for your application - as you said, most likely during startup - but configuration can be changed at any time with no real penalty to the logger's performance or maintainability. This is to enable things like reacting to a spike in errors and dynamically adjusting logging levels so you could, for example, increase the traceability of errors when there's a surge of 5xx.

penna-yaml-config on the other acts as both a file-to-configuration extension and an example implementation of how to interact with penna-api. Although it isn't the most important component of Penna, it is nice to provide something people can use and that can lower the friction - thus yaml, being more common in k8s/docker , is a better choice than xml, for example.

The TL;DR is that Penna provides you with two choices out-of-the-box: Use penna-yaml-config for a low-friction configuration mechanism or interact with the lower-level penna-api for configuring your loggers.

[mikaelstaldal]

Is there any documentation of programmatic configuration? When reading the documentation, you get the impression that YAML file is the only option.