kmesh-net/kmesh

Task description While creating PRs, some commits are failing due to missing Signed-off-by line (DCO check). Currently, this is not clearly mentioned in the contributing guidelines, so new contributors may face confusion. We need to update the contributing guide to include DCO (Developer Certificate of Origin) requirement. Solution Add a small section in the contributing guidelines (under commit message or PR section): Explain that every commit must include: Signed-off-by: Your Name <[email protected]> Mention using: git commit -s to automatically add sign-off (Optional) Add a short note on how to fix missing sign-offs using rebase. Who can join or take the task The good first issue is intended for first-time contributors to get started on his/her contributor journey. After a contributor has successfully completed 1-2 good first issue's, they should be ready to move on to help wanted items, saving the remaining good first issue for other new contributors. How to join or ta

Problem While setting up Kmesh locally, I noticed that the current documentation can be confusing for new contributors, especially around the installation flow. Some key challenges: Istio dependency is not clearly highlighted before deployment The correct setup order is not explicitly defined It is unclear how to verify a successful installation New users may attempt to run kmesh-daemon directly without a Kubernetes environment Proposed Solution I would like to improve the setup documentation by: Adding a "Prerequisites" section (including Istio requirement) Defining a clear setup flow (Kubernetes → Istio → Kmesh) Adding verification steps (e.g., checking running pods) Including a "Common Mistakes" section to avoid confusion Motivation As a new contributor, I faced these issues during setup. Improving the documentation would make onboarding easier for others and reduce setup friction. Additional Context I have successfully set up Kmesh locally and verified the deployment, so I

Currently, when Kmesh encounters an error and passes it up to another part of the program, it often converts that error into a simple text message. While this looks fine in the logs, it creates a problem for the code itself: it "destroys" the original error's identity. If one part of Kmesh needs to know exactly what went wrong (for example, distinguishing between a "Network Timeout" and an "Invalid Secret"), it can no longer do that because the error has been turned into a generic string of text. By using "Error Wrapping" instead, we allow the program to look inside an error message to see the original cause. This enables "smarter" error handling, where the system can automatically retry certain types of failures while stopping for others. Solution: We need to update the way errors are formatted across the project. Instead of just printing the error's text, we should "wrap" the original error so that its type and data remain accessible to other parts of the system.

Task description: At present, enabling and disabling dnsProxy is configured via environment variables. This differs from other functionalities. kmesh/pkg/controller/workload/features.go Lines 22 to 23 in 7c77714 EnableDNSProxy = env.Register("KMESH_ENABLE_DNS_PROXY", false, "When DNS proxy is enabled, a DNS server will be started in kmesh daemon"+ "and serve DNS requests. DNS requests of kmesh-managed pods will be redirected to kmesh daemon.").Get() Solution: Add a startup parameter for the DNS proxy. Ability to autonomously start and stop dnsProxy via kmeshctl. Who can join or take the task: The good first issue is intended for first-time contributors to get started on his/her contributor journey. After a contributor has successfully completed 1-2 good first issue's, they should be ready to move on to help wanted items, saving th