-
Story
-
Resolution: Unresolved
-
Normal
-
None
-
None
⚙️ Automation Task: Log Level Configuration and Validation
This ticket covers the automation of test cases focused on the dynamic configuration and input validation of log levels for all core components managed by the Zero Trust Workload Identity Manager (ZTWIM) Operator. The goal is to ensure logs can be managed via Custom Resources (CRs) and that the system rejects invalid verbosity values, ensuring operational stability.
Components Covered
| Component | CR Managed By | Focus |
|---|---|---|
| *ZTWIM Operator* | Operator Subscription CR | Dynamic Log Level Configuration & Validation |
| *SPIRE Server* | SpireServer CR | Dynamic Log Level Configuration & Validation |
| *SPIRE Agent* | SpireAgent CR | Dynamic Log Level Configuration & Validation |
| *SPIRE OIDC Discovery* | SpireServer CR / Config | Dynamic Log Level Configuration |
📋 Test Cases to Automate
| ID | Component | Objective | Status |
|---|---|---|---|
| 1.1 | ZTWIM Operator | Verify logLevel change via Operator Subscription CR triggers immediate update. | TO DO |
| 1.2 | ZTWIM Operator | Verify ZTWIM Operator rejects and reverts when provided with an invalid log level verbosity value (e.g., '10', 'debugg'). | TO DO |
| 2.1 | SPIRE Server | Verify logLevel change via SpireServer CR triggers update in the SPIRE Server Pod. | TO DO |
| 2.2 | SPIRE Server | Verify SPIRE Server rejects and maintains previous state when provided with an invalid log level value. | TO DO |
| 3.1 | SPIRE Agent | Verify logLevel change via SpireAgent CR triggers update in the SPIRE Agent DaemonSet/Pod. | TO DO |
| 3.2 | SPIRE Agent | Verify SPIRE Agent rejects and maintains previous state when provided with an invalid log level value. | TO DO |
| 4.1 | SPIRE OIDC Discovery | Verify logLevel change via configuration CR (likely part of SpireServer CR) successfully updates the OIDC Discovery service logging. | TO DO |
Acceptance Criteria (ACs)
- All listed test cases are successfully automated and integrated into the existing E2E framework.
- For Successful Log Level Changes: Logs in the respective component Pod/DaemonSet must immediately reflect the new verbosity level (e.g., changing from INFO to DEBUG).
- For Invalid Log Level Inputs (Negative Scenarios):
* The component's log level must remain unchanged.
* The Operator logs must clearly show a reconciliation failure or validation error.
* The component Pod/DaemonSet must remain available and running (no crash/restarts).