[PR] Log to k8s events

[kopf-archiver]

A pull request by nolar at 2019-07-03 08:56:28+00:00
Original URL: zalando-incubator/kopf#128
Merged by nolar at 2019-07-08 13:10:43+00:00

Issue : #136

As a logical continuation of #125:

Description

Kopf is not a K8s API client library. Therefore, it should not provide any means of talking to the K8s API. The operators developers should use the K8s API client libraries of their choice. This also applies to K8s-event posting.

However, Kopf provides few routines for k8s-event posting: kopf.event(), kopf.info(), kopf.warn(), kopf.exception(). This is highly useful for logging not only to the logs (stdout/stderr), but also to K8s itself.

To deal with this dilemma, this PR changes the way how Kopf deals with this specific field — logging to k8s events:

Instead of providing the methods to explicitly post everything in addition to regular logging (thus duplicating the messages and code), everything logged to the per-object logger is now posted to K8s events transparently.

Was:

@kopf.on.create('zalando.org', 'v1', 'kopfexamples')
def create_fn(logger, **kwargs):
    child = _create_child()
    kopf.info("Created a child: %s".format(child.id))
    logger.info("Created a child: %s", child.id)

Now:

@kopf.on.create('zalando.org', 'v1', 'kopfexamples')
def create_fn(logger, **kwargs):
    child = _create_child()
    logger.info("Created a child: %s", child.id)

In the latter case, an k8s-event will be created too.

Only the log messages with level INFO+ will be posted. The DEBUG messages will not be posted (but will be logged as usually).

Only the messages logged to the per-object logger are posted. The rest of the logging machinery is not affected.

The existing k8s-event-posting routines remain in place. They continue to post the events as usually, attached to the specified object (their first positional argument).

All of the internal Kopf-originated events are now also posted that way — via the per-object logger (some were lowered to the DEBUG level to reduce noise).

Types of Changes

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

Review

List of tasks the reviewer must do to review the PR

• Tests
• Documentation