mirror of
https://github.com/kubevela/kubevela.git
synced 2026-02-14 18:10:21 +00:00
e2935da549
Some checks failed
Webhook Upgrade Validation / webhook-upgrade-check (push) Failing after 16m11s
* Docs(KEP): Go SDK for X-Definition Authoring (defkit) Introduces KEP proposal for defkit, a Go SDK that enables platform engineers to author X-Definitions using native Go code instead of CUE. Key proposed features: - Fluent builder API for Component, Trait, Policy, and WorkflowStep definitions - Transparent Go-to-CUE compilation - IDE support with autocomplete and type checking - Schema-agnostic resource construction - Collection operations (map, filter, dedupe) - Composable health and status expressions - Addon integration with godef/ folder support - Module dependencies for definition sharing via go get Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Fix(KEP): Examples and minor api changes given in the document Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Fix(KEP): align defkit examples - Fix golang version in CI - Fix variable declaration in example for testing - Add Is() comparison method to status check Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): add security considerations section - Add goal #7 for secure code execution model - Add Security Considerations section covering: - Code execution model (compile-time only, not runtime) - Security benefits over CUE (static analysis, dependency scanning) - Threat model with mitigations Addresses PR feedback about code execution safety. Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): add module versioning and definition placement sections - Add Module Versioning section explaining git-based version derivation - Add Definition Placement section covering: - Motivation for placement constraints in multi-cluster environments - Fluent API for placement (RunOn, NotRunOn, label conditions) - Logical combinators (And, Or, Not) - Module-level placement defaults - Placement evaluation logic - CLI experience for managing cluster labels - Add Module Hooks section for lifecycle callbacks - Minor fixes and clarifications throughout Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): add module hooks and update addon integration sections - Add Module Hooks section covering: - Use cases (CRD installation, setup scripts, post-install samples) - Hook configuration in module.yaml (pre-apply, post-apply) - Hook types (path for manifests, script for shell scripts) - waitFor field with condition names and CUE expressions - CLI usage (--skip-hooks, --dry-run) - Update Addon Integration section with implementation details: - godef/ folder structure with module.yaml - CLI flags (--godef, --components, --traits, --policies, --workflowsteps) - Conflict detection and --override-definitions flag - Development workflow Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): address PR review comments and clarify placement labels - Fix misleading "Sandboxed Compilation" claim (cubic-ai feedback) - renamed to "Isolated Compilation" and clarified that security relies on trust model, not technical sandboxing - Fix inconsistent apiVersion in module hooks example (defkit.oam.dev/v1 → core.oam.dev/v1beta1) - Clarify that placement uses vela-cluster-identity ConfigMap directly, not the vela cluster labels command (which is planned for future) - Add --stats flag to apply-module CLI documentation Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): fix API documentation Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> * Docs(KEP): add forward-reference for RawCUE() escape hatch Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in> --------- Signed-off-by: Anoop Gopalakrishnan <anoop2811@aol.in>
KubeVela Enhancement Proposals (KEPs)
This directory is a place to propose and discuss new ideas of KubeVela concepts, designs, architectures and techniques.
When do we need KEPs
When major changes are intended to be made to KubeVela project, we need KEPs. Major changes includes:
- New project-level features that add modules to the architecture, like new Controller or APIServer.
- Break changes to the core concepts of KubeVela, such as Application, Workflow, Component, etc.
- Techniques or domains that lots of related enhancements need to be added to KubeVela, like multi-cluster, observability, etc.
Changes to the internal mechanism of core KubeVela are recommended to add proposals as well, including:
- Application behaviours and related policies: State-keep, garbage-collect, resource dispatch, etc.
- API changes of auxiliary resources in KubeVela, such as ApplicationRevision, ResourceTracker.
- New concepts and layers in KubeVela APIServer on VelaUX, such as Project, Target, etc.
Minor changes and enhancements do not necessarily need to be included, but instead recommended to be tracked by issues, such as
- New addons.
- New Component/Trait/WorkflowStep definitions.
- New additional function APIs in APIServer.
- Bug detection and fixes.
- Auxiliary commands in CLI.
Areas
There are several directories contained. Each directory contains the KEPs in specific area.
- /vela-core: The proposals of features and changes to the core KubeVela, including Application APIs, internal mechanisms, auxiliary policies, etc.
- /vela-cli: The proposals of features to the KubeVela CLI, such as
vela top,vela def. - /api: The proposals of the interfaces KubeVela exposes to users, such as command line args for the core controller.
- /platform: The proposals of integrating features in various related areas outside KubeVela, such as edge computing, artificial intelligence.
- /resources: The related images embedded in the design documentations.
Writing a new Proposal
The aim of a proposal is to communicate designs with others and give KubeVela users some basic ideas of how features and evolved and developed.
To reach that, there are several things seed to be included in a proposal.
- The background of the feature or change, which explains why we need it.
- The goals and non-goals for the proposal.
- The potential technical solutions for the proposal and comparisons between various solutions. (Single solution is also acceptable.)
- How we should move on for the proposal. The estimated milestones or timelines for the feature development.
Submitting a new proposal
We recommend to use the template to start a new proposal. After finishing the proposal in the proper directory, raise a pull request to add the proposal to the main repo. If there are any issues related to the proposal, you can also add links to the issues in the pull request.