Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat: Graph-based dependency injection for Kubernetes resources #1404

Open
ffforest opened this issue Feb 6, 2025 · 0 comments
Open

Feat: Graph-based dependency injection for Kubernetes resources #1404

ffforest opened this issue Feb 6, 2025 · 0 comments
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature
Milestone

Comments

@ffforest
Copy link
Contributor

ffforest commented Feb 6, 2025

What would you like to be added?

The dependsOn field for Kubernetes resources in a Spec are currently injected by kusion-module-framework using the OrderedResources method.

The OrderedResources method processes a slice named orderedKinds which takes in a static list of Kubernetes resource Kinds, and process them linearly. This leads to incorrect over-expression of resource dependencies. See the example below in the Why section.

This issue tracks the effort to enable a non-linear, graph-based dependency injection for Kubernetes resources.

Why is this needed?

Background

Kusion currently:

  • uses a slice called DependsOn in generated resources to determine the order to execute resources in a Spec
  • uses a static list of Kinds with fixed order to determine the DependsOn for Kubernetes resources.
  • produces an execution DAG (Directed Acyclic Graph) based on the contents of the DependsOn prior to any execution (preview/apply/destroy) and walk the DAG during execution

For example, assuming the DefaultOrderedKinds contains 4 resource kinds in the following order:

- Namespace
- Secret
- Service
- Deployment

The Generated Spec will contain:

v1:Namespace:NamespaceA:
  ...
v1:Secret:NamespaceA:SecretA:
  ...
  DependsOn:
  - v1:Namespace:NamespaceA
v1:Service:NamespaceA:ServiceA:
  ...
  DependsOn:
  - v1:Namespace:NamespaceA
  - v1:Secret:NamespaceA:SecretA
v1:Deployment:NamespaceA:DeploymentA:
  ...
  DependsOn:
  - v1:Namespace:NamespaceA
  - v1:Secret:NamespaceA:SecretA
  - v1:Service:NamespaceA:ServiceA

The Service for example, may not directly depend on the Secret, but its DependsOn will incorrectly include the Secret because the Secret is defined before Service in the DefaultOrderedKinds

@ffforest ffforest added the kind/feature Categorizes issue or PR as related to a new feature label Feb 6, 2025
@ffforest ffforest assigned ffforest and liu-hm19 and unassigned ffforest Feb 6, 2025
@ffforest ffforest added this to the v0.15.0 milestone Feb 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature
Projects
None yet
Development

No branches or pull requests

2 participants