[PR] Settings (official and documented)

[kopf-archiver]

A pull request by nolar at 2020-03-26 16:55:02+00:00
Original URL: zalando-incubator/kopf#336
Merged by nolar at 2020-03-27 17:48:10+00:00

What do these changes do?

Introduce settings: an official and documented way of configuring of all the little aspects of the framework behaviour on a per-operator basis.

Description

Previously, module-level hacks were used to modify global variables grouped into classes-as-namespaces (beside being undocumented):

import logging
import kopf

# DEPRECATED:
kopf.config.EventsConfig.events_loglevel = logging.WARNING
kopf.config.WatchersConfig.default_stream_timeout = 10 * 60
kopf.config.WorkersConfig.synchronous_tasks_threadpool_limit = 100

@kopf.on.create(...)
def create_fn(**_):
    pass

No more!

Settings are now a part of the framework, and should be defined in the startup handlers:

import logging
import kopf

@kopf.on.startup()
def configure(settings, **_):
    settings.posting.level = logging.WARNING
    settings.watching.stream_timeout = 10 * 60
    settings.execution.limit = 100

@kopf.on.create(...)
def create_fn(**_):
    pass

And there are many more settings (migrated from the existing config classes), and all the new settings will be added to this structure (e.g. a state persistence storage from #331).

import kopf

# NOT YET! SOON. See #331. 
@kopf.on.startup()
def configure(config: kopf.OperatorConfig, **_):
    config.persistence.storage = kopf.AnnotationsStateStorage(prefix='my-opr.example.com')
    # OR:
    config.persistence.storage = kopf.StatusStateStorage(name='my-opr')

Backward-compatibility

The legacy way via module-level config-classes is supported — they are used as the defaults for the settings. BUT: runtime changes of the config-classes are ignored, only the runtime changes of the settings are obeyed.

A special case with the executor of synchronous handlers is supported, and calls to set_synchronous_tasks_threadpool_limit() are forwarded to the settings executor — until config-classes are removed with the next major release (1.0).

---

Beside exposing settings to the users officially, this change also adds a dependency injection mechanics which can be used in the tests instead of mocks — thus making the tests cleaner.

Issues/PRs

Issues: #23

Related: #322 #192 #109

Type of changes

• New feature (non-breaking change which adds functionality)

Checklist

• The code addresses only the mentioned problem, and this problem only
• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes
• If you provide code modification, please add yourself to CONTRIBUTORS.txt

---

Commented by nolar at 2020-03-27 21:49:07+00:00
 

haikoschol Thank you. I've implemented these recommendation with few little additions in #337.