-
Notifications
You must be signed in to change notification settings - Fork 87
Settings (official and documented) #336
Changes from all commits
84b79ac
49fef44
1940afa
773b4ff
4782497
80e8a28
6b0e321
399ae9b
846c1cd
d94070f
a1cf3c2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,135 @@ | ||
============= | ||
Configuration | ||
============= | ||
|
||
There are tools to configure some of kopf functionality, like asynchronous | ||
tasks behaviour and logging events. | ||
|
||
|
||
Startup configuration | ||
===================== | ||
|
||
Every operator has its settings (even if there are more than one operator | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. grammar nit: I'd word it as "... even if there is more than one operator in the same process ..." |
||
in the same processes, e.g. due to :doc:`embedding`). The settings affect | ||
how the framework behaves in details. | ||
|
||
The settings can be modified in the startup handlers (see :doc:`startup`): | ||
|
||
.. code-block:: python | ||
|
||
import kopf | ||
import logging | ||
|
||
@kopf.on.startup() | ||
def configure(settings: kopf.OperatorSettings, **_): | ||
settings.posting.level = logging.WARNING | ||
settings.watching.session_timeout = 1 * 60 | ||
settings.watching.stream_timeout = 10 * 60 | ||
|
||
All the settings have reasonable defaults, so the configuration should be used | ||
only for fine-tuning when and if necessary. | ||
|
||
For more settings, see `kopf.OperatorSettings` and :kwarg:`settings` kwarg. | ||
|
||
|
||
Logging events | ||
============== | ||
|
||
``settings.posting`` allows to control which log messages should be post as | ||
Kubernetes events. Use ``logging`` constants or integer values to set the level: | ||
e.g., ``logging.WARNING``, ``logging.ERROR``, etc. | ||
The default is ``logging`.INFO``. | ||
|
||
.. code-block:: python | ||
|
||
import logging | ||
import kopf | ||
|
||
@kopf.on.startup() | ||
def configure(settings: kopf.OperatorSettings, **_): | ||
settings.posting.level = logging.ERROR | ||
|
||
The event-posting can be disabled completely (the default is to be enabled): | ||
|
||
.. code-block:: python | ||
|
||
import kopf | ||
|
||
@kopf.on.startup() | ||
def configure(settings: kopf.OperatorSettings, **_): | ||
settings.posting.enabled = False | ||
|
||
.. note:: | ||
|
||
These settings also affect `kopf.event` and related functions: | ||
`kopf.info`, `kopf.warn`, `kopf.exception`, etc -- | ||
even if they are called explicitly in the code. | ||
|
||
To avoid these settings having impact on your code, post events | ||
directly with an API client library instead of Kopf-provided toolkit. | ||
|
||
|
||
Synchronous handlers | ||
==================== | ||
|
||
``settings.execution`` allows to set a number of synchronous workers used | ||
and redefined the asyncio executor: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: "redefines", otherwise the sentence might first be parsed as "number of synchronous workers used and redefined". Or even better, find a different word for "redefines" since that suggests the implementation of the executor is changed when I think it just gets reconfigured or maybe another object is instantiated with different parameters? I would also change "a number" to "the number". With the former the sentence can be misunderstood as "some of the synchronous workers are somehow changed". (This is really grammar nitpicking. I expect most people who read this will know what it means as is.) |
||
|
||
.. code-block:: python | ||
|
||
import kopf | ||
|
||
@kopf.on.startup() | ||
def configure(settings: kopf.OperatorSettings, **_): | ||
settings.execution.max_workers = 20 | ||
|
||
|
||
It is possible to replace the whole asyncio executor used | ||
for synchronous handlers (see :doc:`async`). | ||
|
||
Please note that the handlers that started in a previous executor, will be | ||
continued and finished with their original executor. This includes the startup | ||
handler itself. To avoid it, make the on-startup handler asynchronous: | ||
|
||
.. code-block:: python | ||
|
||
import concurrent.futures | ||
import kopf | ||
|
||
@kopf.on.startup() | ||
async def configure(settings: kopf.OperatorSettings, **_): | ||
settings.execution.executor = concurrent.futures.ThreadPoolExecutor() | ||
|
||
|
||
API timeouts | ||
============ | ||
|
||
Few timeouts can be controlled when communicating with Kubernetes API: | ||
|
||
``settings.watching.session_timeout`` (seconds) is how long the session | ||
with a watching request will exist before terminating from the **client** side. | ||
The default is forever (``None``). | ||
|
||
``settings.watching.stream_timeout`` (seconds) is how long the session | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would have never guessed that from the names. How about |
||
with a watching request will exist before terminating from the **server** side. | ||
The default is to let the server decide (``None``). | ||
|
||
It makes no sense to set the client-side timeout shorter than the server side | ||
timeout, but it is given to the developers' responsibility to decide. | ||
|
||
The server-side timeouts are unpredictable, they can be in 10 seconds or | ||
in 10 minutes. Yet, it feels wrong to assume any "good" values in a framework | ||
(especially since it works without timeouts defined, just produces extra logs). | ||
|
||
``settings.watching.retry_delay`` (seconds) is for how long to sleep between | ||
watching requests -- in order to prevent API flooding in case of errors | ||
or disconnects. The default is 0.1 seconds (nearly instant, but no flooding). | ||
|
||
.. code-block:: python | ||
|
||
import concurrent.futures | ||
import kopf | ||
|
||
@kopf.on.startup() | ||
def configure(settings: kopf.OperatorSettings, **_): | ||
settings.watching.stream_timeout = 10 * 60 |
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -38,6 +38,22 @@ in case of retries & errors -- i.e. of the first attempt. | |
in case of retries & errors -- i.e. since the first attempt. | ||
|
||
|
||
.. kwarg:: settings | ||
|
||
Operator configuration | ||
====================== | ||
|
||
``settings`` is passed to activity handlers (but not to resource handlers). | ||
|
||
It is an object with predefined nested structure of containers with values, | ||
which defines the operator's behaviour. See also: `kopf.OperatorSettings`. | ||
|
||
It can be modified if needed (usually in the startup handlers). Every operator | ||
(if there are more than one in the same process) has its own config. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: if there is more than one |
||
|
||
See also: :doc:`configuration`. | ||
|
||
|
||
Resource-related kwargs | ||
======================= | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Tools" makes me think of things like cmdline programs. How about "It is possible to configure..."?