Enhancement

Enhancement

The current schema definitions of Alicloud RDS related resources don't meet the format specification quite well. It is recommended to generate the schema using the kcl-openapi tool and the docstring will be generated from model and attribute description, with a more consistent code format.

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

2. What did you expect to see? (Required)

3. What did you see instead (Required)

4. What is your KusionStack components version? (Required)

General Question

stack.yaml has only one field name...

so as project.yaml..

Bug Report

kusion compile use a spinner style to be user-friendly, but stdout is interrupted, cannot get a valid yaml compiled result.

Use -o option to save compiled result, and compare with std.golden.yaml

General Question

For example,

TEST_A = "a"

TEST_MAP: {str:str} = {
    TEST_A = "b"
}

output:

TEST_A: a
TEST_MAP:
  TEST_A: b

expect:

TEST_A: a
TEST_MAP:
  a: b

@Peefy @chai2010

k8s api :

// EnvVarSource represents a source for the value of an EnvVar.
type EnvVarSource struct {
	// Selects a field of the pod: supports metadata.name, metadata.namespace, `metadata.labels['<KEY>']`, `metadata.annotations['<KEY>']`,
	// spec.nodeName, spec.serviceAccountName, status.hostIP, status.podIP, status.podIPs.
	// +optional
	FieldRef *ObjectFieldSelector `json:"fieldRef,omitempty" protobuf:"bytes,1,opt,name=fieldRef"`
	// Selects a resource of the container: only resources limits and requests
	// (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory and requests.ephemeral-storage) are currently supported.
	// +optional
	ResourceFieldRef *ResourceFieldSelector `json:"resourceFieldRef,omitempty" protobuf:"bytes,2,opt,name=resourceFieldRef"`
	// Selects a key of a ConfigMap.
	// +optional
	ConfigMapKeyRef *ConfigMapKeySelector `json:"configMapKeyRef,omitempty" protobuf:"bytes,3,opt,name=configMapKeyRef"`
	// Selects a key of a secret in the pod's namespace
	// +optional
	SecretKeyRef *SecretKeySelector `json:"secretKeyRef,omitempty" protobuf:"bytes,4,opt,name=secretKeyRef"`
}

Please check the preview report at: https://github.com/KusionStack/konfig/actions/runs/10246228260/artifacts/1775607068

Workflow is pending manual review.
URL: https://api.github.com/KusionStack/konfig/actions/runs/10246228260

Required approvers: [liu-hm19]

Respond "approved", "approve", "lgtm", "yes" to continue workflow or "denied", "deny", "no" to cancel.

there are inconsistencies between docstrings and source code in the docstring-Attributes Part.

for example: (and there are many other similar problems among the repo)
docstring:

source code:

ref: kcl-lang/kcl#281

there are some improper statement about the attribute description in docstring-Attributes Part.

for example:

the attribute image should not be not limited to docker image

Bug Report

1. Minimal reproduce step (Required)

cd appops/http-echo/dev/
kusion apply -y
kubectl describe ingress example-ingress -n http-echo

2. What did you expect to see? (Required)

ingress works as expected

3. What did you see instead (Required)

Name:             example-ingress
Labels:           <none>
Namespace:        http-echo
Address:          
Ingress Class:    nginx
Default backend:  <default>
Rules:
  Host        Path  Backends
  ----        ----  --------
  *           
              /apple   app-service:5678 (<error: endpoints "app-service" not found>)
Annotations:  <none>

4. What is your KusionStack components version? (Required)

releaseVersion: v0.7.1
gitInfo:
    latestTag: v0.7.1
    commit: 10eac925825c1bd087ad590d78670d3bcad6d5fd
    treeState: clean
buildInfo:
    goVersion: go1.17.13
    GOOS: linux
    GOARCH: amd64
    numCPU: 2
    compiler: gc
    buildTime: "2022-11-02 13:04:49"
dependency:
    kclvmgoVersion: v0.4.3
    kclPluginVersion: v0.4.1-alpha2

Enhancement

Add kclvm lint check to Github action, and fix exist lint warnings

k8s api:

InitContainers []Container `json:"initContainers,omitempty" patchStrategy:"merge" patchMergeKey:"name" protobuf:"bytes,20,rep,name=initContainers"`
// List of containers belonging to the pod.
// Containers cannot currently be added or removed.
// There must be at least one container in a Pod.
// Cannot be updated.
// +patchMergeKey=name
// +patchStrategy=merge
Containers []Container `json:"containers" patchStrategy:"merge" patchMergeKey:"name" protobuf:"bytes,2,rep,name=containers"`
// List of ephemeral containers run in this pod. Ephemeral containers may be run in an existing
// pod to perform user-initiated actions such as debugging. This list cannot be specified when
// creating a pod, and it cannot be modified by updating the pod spec. In order to add an
// ephemeral container to an existing pod, use the pod's ephemeralcontainers subresource.
// +optional
// +patchMergeKey=name
// +patchStrategy=merge
EphemeralContainers []EphemeralContainer `json:"ephemeralContainers,omitempty" patchStrategy:"merge" patchMergeKey:"name" protobuf:"bytes,34,rep,name=ephemeralContainers"`

Enhancement

Enhancement

workflow/main.yml provides job "apply", who applies --dry-run. But with the improvement of kusion engine, it cannot work for now.
Besides, does "apply" want to do CI or CD? I prefer the latter. Yt should not in the main.yml which is trigger by push or pullRequest on main, but be a tool which can be used by someone who wants to apply a stack by GitOps.

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

konfig/appops/guestbook-frontend/test/main.k

import base.pkg.kusion_models.test.frontend

appConfiguration: frontend.Server {
}

konfig/appops/guestbook-frontend/test/kcl.yaml

kcl_cli_configs:
  file:
    - main.k
    - ${KCL_MOD}/base/pkg/kusion_models/test/render/render.k

konfig/base/pkg/kusion_models/test/frontend/server.k

schema NewServer:
  a: str

konfig/base/pkg/kusion_models/test/render/render.k

import base.pkg.kusion_models.test.frontend as testFrontend
import base.pkg.kusion_models.kube.frontend


__renderTestServerInstances__ = [inst for inst in testFrontend.NewServer.instances()]
__renderServerFrontendInstances__ = [inst for inst in frontend.Server.instances() if typeof(inst) == "Server"]

2. What did you expect to see? (Required)

kusion compile success.

3. What did you see instead (Required)

3 |appConfiguration: frontend.NewServer {
                        19 ^  -> Failure
      module 'base.pkg.kusion_models.kube.frontend' has no attribute 'NewServer'

4. What is your KusionStack components version? (Required)

releaseVersion: v0.4.4
gitInfo:
    latestTag: v0.4.4
    commit: fd58099d9d38495eabd0dbf78f779c4f5cad0553
    treeState: clean
buildInfo:
    goVersion: go1.17.11
    GOOS: linux
    GOARCH: amd64
    numCPU: 2
    compiler: gc
    buildTime: "2022-06-24 08:40:18"
dependency:
    kclvmgoVersion: v0.4.2-alpha.9
    kclPluginVersion: v0.4.1-alpha2

Enhancement

• We need to provide a web page to display all the model docs (whether they are built-in konfig models or created by users) for the users of the models to quickly obtain an understanding of what these models provide and how to use them.

  • There needs to be a stable web page to display all the model docs
  • The docs need to be synced once the models were released(for example, merged into the main branch)

• We need to provide a reproducible method(maybe a github action template) for users to establish their own automatic document syncing system.

Bug Report

schema field definition and comment are inconsistent, including:

base/pkg/kusion_kubernetes/api

• admissionregistration/v1
• apps/v1
• autoscaling/v1
• batch/v1, batch/v1beta1
• core/v1 (100+ files)
• networking/v1
• rbac/v1

base/pkg/kusion_kubernetes/apimachinery

• apis

base/pkg/kusion_models/kube/

• frontend

base/pkg/kusion_openkruise

• apps/v1
• apps/v1beta1

base/pkg/kusion_prometheus

• monitoring/v1
• monitoring/v1alpha1

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

1. add another component in the appops/guestbook-frontend/base/base.k with following code:

redisLeader: frontend.Server {
    # Main Container Configuration
    mainContainer = container.Main {
        name = "leader"
        ports = [{containerPort = 6379}]
    }
    image = "docker.io/redis:6.0.5"
    selector = {
        "app"  = "redis"
    }
    labels = {
        "app"  = "redis"
        "role" = "leader"
        "tier" = "backend"
    }
    podMetadata.labels: {
        "role" = "leader"
        "tier" = "backend"
        "app"  = "redis"
    }
    schedulingStrategy.resource = res_tpl.tiny
    services = [
        service.Service {
            name = "redis-leader"
            ports = [
                {
                    "port" = 6379
                }
            ]
        }
    ]
}

2. kusion compile -w appops/guestbook-frontend/dev
3. cat appops/guestbook-frontend/dev/ci-test/stdout.golden.yaml

2. What did you expect to see? (Required)

the compiled data contains 2 deployments, 2 service, 1 namespace

3. What did you see instead (Required)

1 deployment, 1 service, 1 namespace

4. What is your KusionStack components version? (Required)

I think it has nothing to do with my kusion version. anyway:

releaseVersion: v0.7.2
gitInfo:
    latestTag: v0.7.2
    commit: fb996130c1e4a8a30da7c04e672433ea6c870384
    treeState: clean
buildInfo:
    goVersion: go1.17.13
    GOOS: linux
    GOARCH: amd64
    numCPU: 2
    compiler: gc
    buildTime: "2022-12-02 07:00:28"
dependency:
    kclvmgoVersion: v0.4.4-alpha.1
    kclPluginVersion: v0.4.1-alpha2

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

konfig/appops/guestbook-frontend/test/main.k

import base.pkg.kusion_models.kube.frontend
import base.pkg.kusion_models.kube.frontend.container
import base.pkg.kusion_models.kube.frontend.container.probe
import base.pkg.kusion_models.kube.frontend.container.lifecycle as lc
import base.pkg.kusion_models.kube.templates.resource as res_tpl

# The application configuration in stack will overwrite
# the configuration with the same attribute in base.
appConfiguration: frontend.Server {
    image = "gcr.io/google-samples/gb-frontend:v4-test"
    schedulingStrategy.resource = res_tpl.tiny


    mainContainer: container.Main {
        lifecycle: lc.Lifecycle {
           preStop = probe.Exec {
               command = ["/bin/sh", "-c", "echo 1"]
           }
        }
    }
}

2. What did you expect to see? (Required)

Kusion compile success.

3. What did you see instead (Required)

 ---> File /Users/liuyan_1/Projects/github/konfig/base/pkg/kusion_models/kube/utils/container_frontend2kube.k:96
      96 |                } if c.lifecycle.preStop.type == "exec" else Undefined -> Failure
      schema 'base.pkg.kusion_models.kube.frontend.container.probe.Exec' attribute 'type' not found

4. What is your KusionStack components version? (Required)

releaseVersion: v0.5.3
gitInfo:
    latestTag: v0.5.3
    commit: 7611976b68b1a5124e801a18a94072222ea88851
    treeState: clean
buildInfo:
    goVersion: go1.17.12
    GOOS: linux
    GOARCH: amd64
    numCPU: 2
    compiler: gc
    buildTime: "2022-08-05 09:10:29"
dependency:
    kclvmgoVersion: v0.4.3-alpha.1
    kclPluginVersion: v0.4.1-alpha2

What would you like to be added?

Support configuration pvc

Why is this needed?

Many scenes need to be used in daily use

What happened?

kusion apply failed because of kclvm.

And it seems that the version of kcl installed in KusionStack/devcontainer-features is not consistent with the actual output kcl version.

@niconical ➜ /workspaces/konfig/code-city/dev (main) $ kusion apply main.k 
 ✘  Compiling in stack dev...                                                                                                                                                                                             
 ❌  Exception: Internal Error! Please report a bug to us: method=ExecProgram, err=Exception=Expecting value: line 1 column 1 (char 0), warn_json_result=called `Result::unwrap()` on an `Err` value: Timeout, stack trace=Traceback (most recent call last):
        File "/home/vscode/.kusion/kclvm/lib/python3.7/kclvm/program/exec/kclvm_cli.py", line 157, in kclvm_cli_native_run_dylib
          panic_info = json.loads(warn_json_result)
        File "/home/vscode/.kusion/kclvm/lib/python3.7/json/__init__.py", line 348, in loads
          return _default_decoder.decode(s)
        File "/home/vscode/.kusion/kclvm/lib/python3.7/json/decoder.py", line 337, in decode
          obj, end = self.raw_decode(s, idx=_w(s, 0).end())
        File "/home/vscode/.kusion/kclvm/lib/python3.7/json/decoder.py", line 355, in raw_decode
          raise JSONDecodeError("Expecting value", s, err.value) from None
      json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
      
      During handling of the above exception, another exception occurred:
      
      Traceback (most recent call last):
        File "/home/vscode/.kusion/kclvm/lib/python3.7/kclvm/internal/gpyrpc/protorpc.py", line 233, in _accept_one_call
          resp = service.call_method(method_name, req)
        File "/home/vscode/.kusion/kclvm/lib/python3.7/kclvm/internal/gpyrpc/gpyrpc_pb_protorpc.py", line 340, in call_method
          return self._instance.ExecProgram(req)
        File "/home/vscode/.kusion/kclvm/lib/python3.7/kclvm/program/rpc-server/__main__.py", line 181, in ExecProgram
          debug=debug,
        File "/home/vscode/.kusion/kclvm/lib/python3.7/kclvm/program/exec/runner.py", line 128, in Run
          return kclvm_cli_native_run_dylib(args)
        File "/home/vscode/.kusion/kclvm/lib/python3.7/kclvm/program/exec/kclvm_cli.py", line 159, in kclvm_cli_native_run_dylib
          raise Exception(f"Exception={e}, warn_json_result={warn_json_result}")
      Exception: Exception=Expecting value: line 1 column 1 (char 0), warn_json_result=called `Result::unwrap()` on an `Err` value: Timeout

What did you expect to happen?

code-city deploy successed.

How can we reproduce it (as minimally and precisely as possible)?

1. Click Kusion in Codespaces.
2. kusion init --online and then select code-city
3. cd code-city/dev && kusion apply main.k

Anything else we need to know?

No response

Kusion version

@niconical ➜ ~/.kusion/kclvm/bin $ kclvm_cli --version
kcl 
@niconical ➜ ~/.kusion/kclvm/bin $ kcl --version
kclvm version is 0.4.3; checksum: e07ed7af0d9bd1e86a3131714e4bd20c

@niconical ➜ ~/.kusion/kclvm/bin $ kcl-go --version
kcl-go version (devel)

OS version

@niconical ➜ ~/.kusion/kclvm/bin $ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Install tools

Enhancement

Add shcema KubeVelaAppConfig like the existed schema Server to support both KubeVela and IaaS resources. We can convert K8s resources to KubeVela Application and Iaas resources to TF resources.

More details can be found here kubevela/kubevela#5219

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

• test.k

import pkg

mixin XMixin:
    server: pkg.Server {}

2. What did you expect to see? (Required)

Compile successed.

3. What did you see instead (Required)

KCL Compile Error[E2L23] : A complie error occurs during compiling
---> File test.k:4:5
4 |    server: pkg.Server {}
     5 ^  -> Failure
'pkg' refers to a value, but is being used as a type here

I use the code below to walk around and need KCLVM to fix this:

import pkg

mixin XMixin:
    if True:
        server: pkg.Server {}

4. What is your KusionStack components version? (Required)

kclvm version is 0.4.2

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

cd appops/http-echo/dev
kusion compile

2. What did you expect to see? (Required)

nothing changed

3. What did you see instead (Required)

the appops/http-echo/dev/ci-test/stdout.golden.yaml file content changed

4. What is your KusionStack components version? (Required)

releaseVersion: v0.7.2
gitInfo:
    latestTag: v0.7.2
    commit: fb996130c1e4a8a30da7c04e672433ea6c870384
    treeState: clean
buildInfo:
    goVersion: go1.17.13
    GOOS: linux
    GOARCH: amd64
    numCPU: 2
    compiler: gc
    buildTime: "2022-12-02 07:00:28"
dependency:
    kclvmgoVersion: v0.4.4-alpha.1
    kclPluginVersion: v0.4.1-alpha2

Feature Request

As title says, rbac resources has no frontend or backend models, kusion compile cannot generate ID+Type+Attribute+DependsOn output, which relies on output_type_mixin

What would you like to be added?

Upgrade Konfig as the Kusion example repo and all examples should be upgraded with kpm

Why is this needed?

The old model rendering method has been deprecated.

ref: https://monitoring.mixins.dev/kubernetes/#kubernetes-apps

TODO list of writing PrometheusRules in KCL:

1. generate prometheus models
   a. Prometheus
   b. PrometheusRule
   c. Alertmanager
   d. AlertmanagerConfig
   e. ServiceMonitor
   f. PodMonitor
2. a project of prometheus install
3. example rules and alert
4. doc: install alertmanager cluster, integrating with prometheus
5. doc: recording rules and alert rules

Background

Those golden files are used mainly for the smoking test, listing affected stacks and displaying the expected YAML diffs in the PR CI progress. But the downsides are appearing:

• The golden files costumes lots of storage and slows down code fetching from GitHub: line count: 237w(golden.yaml) vs 70w(.k); file count: 8449(golden.yaml) vs 13381(.k)
• users must locally re-compile all the affected stacks to the corresponding stdout.golden.yaml files. That's time-consuming. And it's also not evident to users who are first to the Kusion stack.
• during the ci test, the golden files must be checked with the compiled output in the CI. That's time-consuming. And if users always compile locally, the CI process is barely checking if the output compiled in during CI is exactly the same as that compiled by users' local machine. And that's not very meaningful for the configuration correctness.
• the committed golden files are easily conflict when there are multiple modifications on the stack and the base schemas in parallel.

For all the above reasons, The golden files need to be removed from the repo, on the premise that all the usages of them are reserved:

• changes in files cannot break the compilability. If so, that change should be blocked in the CI process.
• Users can review the low-level data changes that the code change brings: The CI process should list all the affected stacks and display the data diffs that the PR brings.

Furthermore, the stability of the code in konfig still needs to be enhanced by unit and end-to-end tests. That will be discussed in issue: todo

Solution

Tools

Update: kusion compile

Current

usage is:kusion compile -w <stackPath>. When the -o option is not specified, the command will by default output to the ci-test/stdout.golden.yaml file.

Update to

• by default output to the stdout stream.
• add a --front option to output the frontend configuration.

Optimize: kusion deps

The kusion deps tools should be optimized to identify the configuration changes more precisely, so to reduce the re-compile time, then improve the local and the CI efficiency.

Current

The dependency analysis is based on the import relationship between files.

Update to

The kusion deps tool should support attribute-level dependency analysis.

Update: CI

The CI pipeline needs to support listing affected stacks and the diff details:

• list affected stacks
• show diffs of affected stacks

Update: Konfig script

• remove the check-App script
• support viewing Yaml format diff of specific app configuration
• support listing changed stacks after modifying the basic logic.

Add: Kusion IDE

Kusion IDE needs to provide convenient user interaction based on the above tools:

live preview of app configuraiton's Yaml representation

the feature is detailed in: kcl-lang/vscode-kcl#14

Provide a preview Yaml output panel when the user's active editor is at a base.k/main.k file under a stack:

• the Yaml output preview could be live according to the KCL code modification.
• the live preview supports either frontend preview or backend preview to satisfy the requirements of both app owners and lib maintainers
• when the user is adopting a source control, the live preview could provide the highlighted diff of the Yaml data according to changes on the source code.
• asynchronously check the affected stacks' compilability. And before the user commits to the source control, use the pre-commit hook to check if the app configurations within all the stacks are valid.

filter and focus on the changed stacks to provide a local review

Provide filters when displaying the konfig apps:

• based on the dependency relationship to filter the stacks. the upstream could be user-defined or from the git diff change.
• based on the app name, or the app type, or the organization architecture, ..., to filter the stacks

change review panel

If the repo is adopting a source control, the Kusion IDE needs to add a panel to display the changed stack list and a left-to-right Yaml diff of stacks, so users could review these changes before committing.

The related components need to be updated

There are some components that are aware of or rely on the stdout.golden.yaml files. They need to be updated before the golden files are finally removed from the konfig repo:

• The New App Releasement component
• The Kusion server
• The ci component and scripts
• The locally used scripts in konfig repo
• The documents that are spread over many teams and scenarios
• The examples to use kusion
• ats platforms

During the migration, deprecated warnings could be widely used to inform users to migrate to the new process. And users should be announced before the changes are public released.

Phased Goals

stage 1:

• Kusion IDE: support preview YAML data: frontend & backend
• kusion compile: remove default output to golden
• ci pipeline: show YAML diff in stacks between the target branch and the source branch

stage 2:

• optimize the kusion deps tool to support attribute-level dependency analysis.
• Kusion IDE: support list stack diffs triggered by certain changes.

Please check the preview report at: https://github.com/KusionStack/konfig/actions/runs/9499877053/artifacts/1598016591

Workflow is pending manual review.
URL: https://api.github.com/KusionStack/konfig/actions/runs/9499877053

Required approvers: [SparkYuan]

Respond "approved", "approve", "lgtm", "yes" to continue workflow or "denied", "deny", "no" to cancel.

Feature Request

Is your feature request related to a problem? Please describe:

Describe the feature you'd like:

Describe alternatives you've considered:

Teachability, Documentation, Adoption, Migration Strategy:

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

konfig/appops/guestbook-frontend/base/main.k

import base.pkg.kusion_models.kube.frontend
import base.pkg.kusion_models.kube.frontend.container
import base.pkg.kusion_models.kube.frontend.container.env as e
import base.pkg.kusion_models.kube.templates.resource as res_tpl

# Application Configuration
appConfiguration: frontend.Server {
    # Main Container Configuration
    mainContainer = container.Main {
        name = "php-redis"
        env: [e.Env {
                name = "GET_HOSTS_FROM"
                value = "dns"
        }]
        ports = [{containerPort = 80}]
    }
    selector = {
        "tier" = "frontend"
    }
    podMetadata.labels: {
        "tier" = "frontend"
    }
    schedulingStrategy.resource = res_tpl.medium
}

konfig/appops/guestbook-frontend/test/main.k

import base.pkg.kusion_models.kube.frontend
import base.pkg.kusion_models.kube.frontend.container
import base.pkg.kusion_models.kube.frontend.container.env as e
import base.pkg.kusion_models.kube.templates.resource as res_tpl

# the configuration with the same attribute in base.
appConfiguration: frontend.Server {
    image = "gcr.io/google-samples/gb-frontend:v4-test"
    schedulingStrategy.resource = res_tpl.tiny

    mainContainer = container.Main {
      env: [e.Env {
          name: "TEST"
          value: "test"
      }]
    }
}

2. What did you expect to see? (Required)

Kusion compile success.

3. What did you see instead (Required)

13 |      env: [e.Env { -> Failure
      conflicting values on the attribute 'name' between {'__settings__': {'output_type': 'INLINE', '__schema_name__': 'Env', '__schema_type__': 'base.pkg.kusion_models.kube.frontend.container.env.Env', '__pkg_path__': 'base.pkg.kusion_models.kube.frontend.container.env'}, 'name': 'GET_HOSTS_FROM', 'value': 'dns', 'valueFrom': Undefined} and {'__settings__': {'output_type': 'INLINE', '__schema_name__': 'Env', '__schema_type__': 'base.pkg.kusion_models.kube.frontend.container.env.Env', '__pkg_path__': 'base.pkg.kusion_models.kube.frontend.container.env'}, 'name': 'TEST', 'value': 'test', 'valueFrom': Undefined}

4. What is your KusionStack components version? (Required)

releaseVersion: v0.5.3
gitInfo:
    latestTag: v0.5.3
    commit: 7611976b68b1a5124e801a18a94072222ea88851
    treeState: clean
buildInfo:
    goVersion: go1.17.12
    GOOS: linux
    GOARCH: amd64
    numCPU: 2
    compiler: gc
    buildTime: "2022-08-05 09:10:29"
dependency:
    kclvmgoVersion: v0.4.3-alpha.1
    kclPluginVersion: v0.4.1-alpha2

Enhancement

the test job in the ci pipeline is now roughly separated into "biz" and "base" to save time when only "configuration data in stacks" changed. But it is not good enough: when base lib files change, all the stacks will be tested.

The ci pipeline should support dependency analysis and only trigger tests on projects/stacks affected by the file change.

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

konfig/appops/guestbook-frontend/test

import base.pkg.kusion_models.kube.frontend
import base.pkg.kusion_models.kube.frontend.container
import base.pkg.kusion_models.kube.templates.resource as res_tpl

# The application configuration in stack will overwrite
# the configuration with the same attribute in base.
appConfiguration: frontend.Server {
    image = "gcr.io/google-samples/gb-frontend:v4-test"
    schedulingStrategy: {
        resource = "1<cpu<2,1Gi<memory<2Gi"
    }
}

2. What did you expect to see? (Required)

Kusion compile success.

3. What did you see instead (Required)

 ---> File /Users/liuyan_1/Projects/konfig/base/pkg/kusion_models/kube/utils/str2resource_requirements.k:31
      31 |            "ephemeral-storage" = resource?[0]?.disk?.requests or resource?[1]?.disk?.requests or resource?[2]?.disk?.requests -> Failure
      list index out of range

4. What is your KusionStack components version? (Required)

releaseVersion: v0.5.3
gitInfo:
latestTag: v0.5.3
commit: 7611976b68b1a5124e801a18a94072222ea88851
treeState: clean
buildInfo:
goVersion: go1.17.12
GOOS: linux
GOARCH: amd64
numCPU: 2
compiler: gc
buildTime: "2022-08-05 09:10:29"
dependency:
kclvmgoVersion: v0.4.3-alpha.1
kclPluginVersion: v0.4.1-alpha2

General Question

When users want to use 2048Mi memory, for example, and we set resources.memroy.limits = 2048Mi, but set resources.memroy.requests = 2048Mi * (a float ratio).

import units
import base.pkg.kusion_models.kube.frontend.resource

a: units.NumberMultiplier = 2048Mi
ratio: float = 0.01

res: resource.Resource = {
    cpu = 1 * ratio        # How to convert to "10m"?
    memory = a * ratio  # error: unsupport
    #memory = units.to_Mi(float(int(a)) * ratio) # error: to_Mi unsupport a float argument
}

@Peefy @chai2010

please make it consistent with the corresponding example in https://github.com/kubernetes/examples/tree/master/guestbook

What would you like to be added?

Add a tutorial on how to develop models to minimize the learning curve of developing models

Why is this needed?

We have no development tutorial on developing Konfig for newcomers

Task list

• outline
• development guide

Feature request

Now creating a new codespace with konfig's devcontainer.json needs about 3min to prepare the environment. That's time-consuming and can be speeded up by configuring a prebuild.

To enable prebuild, our KusionStack organization needs to pay for the compute and storage costs.

cost estimate

Here's the estimated cost for one year's usage: 72 dollars per year

• basic: 48 dollars per year
• (10min each prebuild) * (30 repeated prebuild each month) * (2core) / (60min) * (0.18 dollar) = 1.8 dollars per month
• (0.1 GB each prebuild) * (30 repeated prebuild each month)*(0.01dollar) = 0.1 dollar per month

time consumption

A successful prebuild of minikube+kusion env costs about 5-7 min.

trigger policy

The prebuild process can be triggered in 3 kinds of scheduling policies:

• Every push (the default setting) - With this setting, prebuilds will be updated on every push made to the given branch.
• On configuration change - With this setting, prebuilds will be updated every time associated configuration files for a given repo and branch are updated.
• Scheduled - With this setting, you can have your prebuilds updated on a custom schedule that's defined by you.
  And to meet our needs, we can choose the second one: trigger prebuild each time the .devcontainer.json is changed.

ref:

• https://github.com/features/codespaces
• github pricing
• enabling github codespaces for your organization
• billing for codespaces
• configure prebuild
• Set a spending limit

And..., no it can not be self-hosted, so the prebuild process make use of our computing & storage resources bought from Aliyun & AWS:

Please check the preview report at: https://github.com/KusionStack/konfig/actions/runs/9480296729/artifacts/1593148763

Workflow is pending manual review.
URL: https://github.com/KusionStack/konfig/actions/runs/9480296729

Required approvers: [liu-hm19]

Respond "approved", "approve", "lgtm", "yes" to continue workflow or "denied", "deny", "no" to cancel.

Enhancement

the test reports are now uploaded as artifacts and can be displayed more intuitively by adapting, for example, some test reporter github action: https://github.com/marketplace/actions/test-reporter

Feature Request

Is your feature request related to a problem? Please describe:

Describe the feature you'd like:
As we known, OpenKruise is a popular solution which extend and complement the Kubernetes core controllers for workload and application management. So if we support OpenKruise in konfig as a base model, it will extend the border of Kusion.

Describe alternatives you've considered:

Teachability, Documentation, Adoption, Migration Strategy:

Please check the preview report at: https://github.com/KusionStack/konfig/actions/runs/9410810943/artifacts/1577593488

Workflow is pending manual review.
URL: https://github.com/KusionStack/konfig/actions/runs/9410810943

Required approvers: [liu-hm19]

Respond "approved", "approve", "lgtm", "yes" to continue workflow or "denied", "deny", "no" to cancel.