Table of Contents |
---|
Status
Current state: Under discussionAccepted
Discussion thread: here
Voting thread: here
JIRA: here
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
...
Workers that have not yet completed startup will ignore these records, including if the worker reads one during the read-to-end of the config topic that all workers perform during startupof the config topic that all workers perform during startup. Restarting a worker will cause it to discard all cluster-wide dynamic log level adjustments, and revert to the levels specified in its Log4j configuration. This mirrors the current behavior with per-worker dynamic log level adjustments.
There may be some delay between when a REST request with scope=cluster
is received and when all workers have read the corresponding record from the config topic. The last modified timestamp (details above) can serve as a rudimentary tool to provide insight into the propagation of a cluster-wide log level adjustment.
Standalone mode
Given that standalone mode by definition only supports one worker, this feature does not seem applicable on the surface. And, for the underlying dynamic log adjustment logic, no changes will be made. However, for the sake of consistency with distributed mode, the scope
query parameter will still be recognized and, if set to cluster
, will cause a 204 response with no body to be returned.
...
- Start a distributed Connect cluster with three workers
- Ensure that the last modified timestamp for all reported logging namespaces is null
- Modify the logging level for a specific namespace for single worker
- Ensure that the response body is non-empty and matches the same format it had prior to this KIP
- Ensure that the last modified timestamp for that namespace on the affected worker is non-null and at least as recent as the time at which the request was issued (some margin of error may be necessary in the highly unlikely but technically possible event that the node responsible for running tests and the one running the worker have skewed clocks)
- Ensure that the logging level for that namespace on the affected worker is reported (via the admin REST API) with the correct level
- Ensure that the last modified timestamp for that namespace on all other workers is still null
- Ensure that the logging level for that namespace on all other workers is unchanged
- Modify the logging level for the root namespace for all workers (using
scope=cluster
)- Ensure that the response body is empty
- Ensure that, after a reasonable timeout, the logging level for all reported namespaces on all workers is reported with the correct level
- Ensure that the last modified timestamp for all namespaces on all workers is non-null and at least as recent as the time at which the request was issued
- Modify the logging level for a specific namespace for all workers (using
scope=cluster
)- Ensure that the response body is empty
- Ensure that, after a reasonable timeout, the logging level for that namespace on all workers is reported with the correct level
- Ensure that the last modified timestamp for that namespace on all workers is non-null and at least as recent as the time at which the request was issued
- Issue a second request to set the same logging level for the same namespace for all workers (using
scope=cluster
)- No assertions will be made for this step
- Modify the logging level for a different specific namespace for all workers (using
scope=cluster
)- Ensure that, after a reasonable timeout, the logging level for that namespace on all workers is reported with the correct level
- Ensure that the last modified timestamp for that namespace on all workers is non-null and at least as recent as the time at which the request was issued
- Ensure that the last modified timestamp for the namespace affected in steps 4 and 5 is unchanged from when it was tested in step 4 (i.e., the second request in step 5 did not affect it)
- Modify the logging level for the root namespace for all workers (using
scope=cluster
)- No assertions will be made for this step
- Modify the logging level for a specific namespace for a single worker (again)
- Ensure that the response body is non-empty and matches the same format it had prior to this KIP
- Ensure that the last modified timestamp for that namespace on the affected worker is at least as recent as the time at which the request was issued
- Ensure that the logging level for that namespace on the affected worker is reported with the correct level
- Ensure that the last modified timestamp for all namespaces except the modified namespace on the affected worker, and all namespaces for all other workers, is unchanged since the root level was modified for all workers*
- Ensure that the logging levels for all namespaces except the modified namespace on the affected worker, and all namespaces for all other workers, is unchanged since the root level was modified for all workers*
...