Krkn Roadmap
Krkn Roadmap
Following are a list of enhancements that we are planning to work on adding support in Krkn. Of course any help/contributions are greatly appreciated.
- Ability to visualize the metrics that are being captured by Kraken and stored in Elasticsearch
- Ability to roll back cluster to original state if chaos fails
- Add recovery time metrics to each scenario for better regression analysis
- Add resiliency scoring to chaos scenarios ran on cluster
- Add AI-based Chaos Configuration Generator
- Introduce Security Chaos Engineering Scenarios
- Add AWS-native Chaos Scenarios (S3, Lambda, Networking)
- Unify Krkn Ecosystem under krknctl for Enhanced UX
- Build Web UI for Creating, Monitoring, and Reviewing Chaos Scenarios
- Add Predefined Chaos Scenario Templates (KRKN Chaos Library)
- Ability to run multiple chaos scenarios in parallel under load to mimic real world outages
- Centralized storage for chaos experiments artifacts - PR #758
- Support for causing DNS outages - PR #856
- Chaos recommender to suggest scenarios having probability of impacting the service under test using profiling results - PR #508
- Chaos AI integration to improve test coverage while reducing fault space to save costs and execution time krkn-chaos-ai
- Support for pod level network traffic shaping - PR #449, PR #501
- Support for running all the scenarios of Kraken on Kubernetes distribution - see https://github.com/krkn-chaos/krkn/issues/185, https://github.com/redhat-chaos/krkn/issues/186
- Continue to improve Chaos Testing Guide in terms of adding best practices, test environment recommendations and scenarios to make sure the OpenShift platform, as well the applications running on top it, are resilient and performant under chaotic conditions.
- Switch documentation references to Kubernetes
- OCP and Kubernetes functionalities segregation - PR #507
- Krknctl - client for running Krkn scenarios with ease
- AI Chat bot to help get started with Krkn and commands
Proposing a Roadmap Item
Anyone in the community can propose an item for the roadmap. The process is designed to be lightweight and transparent.
Step 1 — Open a GitHub Issue
Open a new feature request issue describing what you want to add and why. A strong proposal includes:
- Problem statement – what gap or limitation exists today
- Proposed solution – what the feature would do at a high level
- Scope – is this a small enhancement, a new scenario, or a large architectural change?
- Benefit to the community – who would use this and how
Add the label roadmap-proposal to the issue so maintainers can find it easily.
Step 2 — Community Discussion
Leave the issue open for community feedback for at least two weeks. Gather responses from users and contributors — this helps maintainers understand demand and surface edge cases before committing it to the roadmap.
You can also raise the proposal in the #krkn channel on Kubernetes Slack or bring it to the monthly office hours for live discussion.
Step 3 — Maintainer Review and Decision
Maintainers review roadmap-proposal issues at the monthly community meeting or asynchronously via the issue thread. A simple majority vote of Maintainers is required to add an item to the roadmap (see GOVERNANCE.md).
Items are evaluated against the following criteria:
| Criterion | Description |
|---|---|
| Alignment | Does it fit the project’s mission of chaos and resiliency testing for Kubernetes? |
| Impact | Does it benefit a broad set of users or address a common pain point? |
| Feasibility | Is it technically achievable with reasonable effort? |
| Ownership | Is there a contributor willing to drive implementation? |
Step 4 — Added to the Roadmap
If approved, a maintainer opens a PR to add the item to this file under the open ([ ]) section. The PR should link to the original proposal issue. Do not begin implementation until the roadmap PR is merged — that merge is the signal that the item is officially accepted.
Once the item is on the roadmap, comment on the issue to request assignment before starting work. The contributor who originally proposed the issue is given priority, but if they are not planning to implement it, any community member can be assigned. Maintainers may also pick up items independently if no one has claimed them.
Step 5 — Implementation and Completion
When the feature is implemented, the roadmap item is updated to checked ([x]) and the implementing PR link is added. The proposal issue is then closed.