kubevela / kubevela Goto Github PK

View Code? Open in Web Editor NEW

6.1K 110.0 855.0 63.85 MB

The Modern Application Platform.

Home Page: https://kubevela.io

License: Apache License 2.0

Dockerfile 0.03% Makefile 0.32% Go 93.14% Shell 0.38% Mustache 0.86% CUE 5.25% HCL 0.02%

oam kubernetes application microservices serverless cloudnative trait workloads cue helm

kubevela's Introduction

Make shipping applications more enjoyable.

Introduction

KubeVela is a modern application delivery platform that makes deploying and operating applications across today's hybrid, multi-cloud environments easier, faster and more reliable.

Highlights

KubeVela practices the "render, orchestrate, deploy" workflow with below highlighted values added to existing ecosystem:

Deployment as Code

Declare your deployment plan as workflow, run it automatically with any CI/CD or GitOps system, extend or re-program the workflow steps with CUE. No ad-hoc scripts, no dirty glue code, just deploy. The deployment workflow in KubeVela is powered by Open Application Model.

Built-in observability, multi-tenancy and security support

Choose from the wide range of LDAP integrations we provided out-of-box, enjoy enhanced multi-tenancy and multi-cluster authorization and authentication, pick and apply fine-grained RBAC modules and customize them as per your own supply chain requirements. All delivery process has fully automated observability dashboards.

Multi-cloud/hybrid-environments app delivery as first-class citizen

Natively supports multi-cluster/hybrid-cloud scenarios such as progressive rollout across test/staging/production environments, automatic canary, blue-green and continuous verification, rich placement strategy across clusters and clouds, along with automated cloud environments provision.

Lightweight but highly extensible architecture

Minimize your control plane deployment with only one pod and 0.5c1g resources to handle thousands of application delivery. Glue and orchestrate all your infrastructure capabilities as reusable modules with a highly extensible architecture and share the large growing community addons.

Getting Started

Documentation

Full documentation is available on the KubeVela website.

Blog

Official blog is available on KubeVela blog.

Community

We want your contributions and suggestions! One of the easiest ways to contribute is to participate in discussions on the Github Issues/Discussion, chat on IM or the bi-weekly community calls. For more information on the community engagement, developer and contributing guidelines and more, head over to the KubeVela community repo.

Contact Us

Reach out with any questions you may have and we'll make sure to answer them as soon as possible!

Slack: CNCF Slack kubevela channel (English)
DingTalk Group: 23310022 (Chinese)
Wechat Group (Chinese): Broker wechat to add you into the user group.

Community Call

Every two weeks we host a community call to showcase new features, review upcoming milestones, and engage in a Q&A. All are welcome!

Bi-weekly Community Call:
- Meeting Notes.
- Video Records.
Bi-weekly Chinese Community Call:
- Video Records.

Talks and Conferences

Check out KubeVela videos for these talks and conferences.

Contributing

Check out CONTRIBUTING to see how to develop with KubeVela.

Report Vulnerability

Security is a first priority thing for us at KubeVela. If you come across a related issue, please send email to [email protected] .

Code of Conduct

KubeVela adopts CNCF Code of Conduct.

kubevela's People

Contributors

Stargazers

Watchers

Forkers

zzxwill erdun baikai ryanzhang-oss resouer isgasho u2bo wenxinnnnn zeusro captainroy-hy wonderflow glacier759 hongchaodeng anhongbin silenceper xiaoyuaiheshui sandeepk17 eagle9527 diddaa leoliuyan aichovy szihai fei-guo jz0630 hfq-xuhengtong silotrd fillzpp ikingye tossmilestone sunny0826 furykerry lujinda dimpu47 ming535 liccol icefoxs liyongxian wfvkvh morlay jackcst cimomo hongzhenglin cnhup dut3062796s roofxixi cmcc-ict hadoop835 jangocheng arvisha16 jerryhu1234 leonrodenburg handong890 weibaohui lyrl global-localhost zazalee xiaoxiao-clound nkgfirecream songdantes horis233 forcoder soyoo aylei yianz ycy-repo leejanee anarcher gavinfish fengxsong laojianzi wubiaowp mclouding gitobjects bellondr zwqzwq123 hiprobert lllwan huqian19860722 monkeywie qiaomaifu qwb2013 jasenzhang likofans cobra180825 majian159 jyniki dystudio ophira0110 fhchina heifire shirleyee keonjeo 912988434 cweiping etherealand jangocity nlg521 yassokang elementakgod linzengfa

kubevela's Issues

[feature]Use deployment as default workload and align parameters with rio

https://github.com/rancher/rio/blob/v0.6.0/docs/workloads.md

[Feature] show: get detail spec of your app

This command should show app info like this:

$ rudr show frontend
About:
   Appset: myapp
   ENV: test
ComponentType: deployment
  image: oam/dev:v1
  port: 8080
Route:
  domain: example.com

Error: list workload Definition err: an empty namespace may not be set when a resource name is provided

➜  /Users/zhouzhengxi/Programming/golang/src/github.com/zzxwill/RudrX/cmd/rudrx git:(master) ✗ go run main.go run containerizedworkload app -n default
Error: list workload Definition err: an empty namespace may not be set when a resource name is provided
Usage:
  rudrx run [WORKLOAD_KIND] [args]

Examples:

  rudrx run containerized frontend -p 80 oam-dev/demo:v1


Flags:
  -h, --help   help for run

Global Flags:
      --as string                      Username to impersonate for the operation
      --as-group stringArray           Group to impersonate for the operation, this flag can be repeated to specify multiple groups.
      --cache-dir string               Default HTTP cache directory (default "/Users/zhouzhengxi/.kube/http-cache")
      --certificate-authority string   Path to a cert file for the certificate authority
      --client-certificate string      Path to a client certificate file for TLS
      --client-key string              Path to a client key file for TLS
      --cluster string                 The name of the kubeconfig cluster to use
      --context string                 The name of the kubeconfig context to use
      --insecure-skip-tls-verify       If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure
      --kubeconfig string              Path to the kubeconfig file to use for CLI requests.
  -n, --namespace string               If present, the namespace scope for this CLI request
      --password string                Password for basic authentication to the API server
      --request-timeout string         The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0")
  -s, --server string                  The address and port of the Kubernetes API server
      --tls-server-name string         Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used
      --token string                   Bearer token for authentication to the API server
      --user string                    The name of the kubeconfig user to use
      --username string                Username for basic authentication to the API server

[feature] Add and update subcommand of `make`

add make build command, build the binary of rudr
make install depends on kustomize, which should only depend on kubectl
add e2e test command make test e2e
add make clean command
IMG ?= controller:latest need to change the image name

[feature] support auto generate definition files

The overall idea is to generate workloaddefinition, traitdefinition, scopedefinition Automatically.

rudr generate workload deployments.apps
rudr generate trait routes.serving.knative.dev

rudr generate workload --group apps.kruise.io

[CI] Add Robot and run CI before merging

Add Robot and run CI before merging

[BUG] Application created with wrong workload if there are more than one workloaddefinition

There are more than one workloaddefinitions.

➜  /Users/zhouzhengxi/Programming/golang/src/github.com/cloud-native-application/RudrX git:(e2e) ✗ k get workloaddefinition
NAME                                  DEFINITION-NAME
containerizedworkloads.core.oam.dev   containerizedworkloads.core.oam.dev
deployments.apps                      deployments.apps

Run rudr run containerized app-testworkloadrun-basic -p 80 nginx:1.9.4 to create an application. We found the expected workload wasn't containerized.

➜  /Users/zhouzhengxi/Programming/golang/src/github.com/cloud-native-application/RudrX git:(e2e) ✗ k get applicationconfiguration
NAME                        AGE
app-testworkloadrun-basic   39s
➜  /Users/zhouzhengxi/Programming/golang/src/github.com/cloud-native-application/RudrX git:(e2e) ✗ k get applicationconfiguration app-testworkloadrun-basic -p yaml
Error: unknown shorthand flag: 'p' in -p
See 'kubectl get --help' for usage.
➜  /Users/zhouzhengxi/Programming/golang/src/github.com/cloud-native-application/RudrX git:(e2e) ✗ k get applicationconfiguration app-testworkloadrun-basic -o yaml
apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  creationTimestamp: "2020-07-31T03:21:34Z"
  generation: 1
  name: app-testworkloadrun-basic
  namespace: default
  resourceVersion: "12355749"
  selfLink: /apis/core.oam.dev/v1alpha2/namespaces/default/applicationconfigurations/app-testworkloadrun-basic
  uid: 5ea82dd9-f5a7-413b-a7c2-1d09e6cdedc6
spec:
  components:
  - componentName: app-testworkloadrun-basic

➜  /Users/zhouzhengxi/Programming/golang/src/github.com/cloud-native-application/RudrX git:(e2e) ✗ k get component app-testworkloadrun-basic -o yaml
apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  creationTimestamp: "2020-07-31T03:21:34Z"
  generation: 1
  name: app-testworkloadrun-basic
  namespace: default
  resourceVersion: "12355747"
  selfLink: /apis/core.oam.dev/v1alpha2/namespaces/default/components/app-testworkloadrun-basic
  uid: 6de83a51-0b9f-4019-84b0-306d752dddd2
spec:
  workload:
    apiVersion: core.oam.dev/v1alpha2
    kind: deployment
    metadata:
      name: app-testworkloadrun-basic
    spec:
      containers:
      - image: nginx:1.9.4
        name: master
        ports:
        - containerPort: 80
          name: tbd
          protocol: TCP
status:
  latestRevision:
    name: app-testworkloadrun-basic-bshoshbd0cvka7locstg
    revision: 1

[Discussion] renaming `rudr bind` to `rudr attach`

In the original design specs, we use rudr bind to attach a trait to a component. @hongchaodeng suggested me to use rudr attach instead. I check that Heroku also uses a similar command heroku addon:attach to bind a backing service, operation tool to a component https://docs.google.com/document/d/1nSLcklrSg38GAdqJNFZIgjpb2X9_6cCm8wl8bgJnjog/edit#heading=h.6yuoa46ooqhf.

So I propose for the renaming.

setup CI and make unit test run for this project

create github action
make unit test run

[feature]Support build image from source code (CI/CD pipeline)

We can follow knative tecton build

Move root command to cmd/root.go

Move root command from main.go to cmd/root.go, just import root command and execute in main.go.
There are 2 considers:

Add test root command and keep main.go clean in cmd directory.
Root command and subcommands are in the same package and share variables.

[feature] Release and Rollback of the app

Ref: https://devcenter.heroku.com/articles/glossary-of-heroku-terminology#release

Some corner cases which might need to cover.

Somehow workload-definitions are not pre-applied.

[feature]Support type for parameter

At least, we need support below four types:

string
int
float
image: special type, it's real type is string, but can do more, such as build image from source code(git url).

apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
...
    parameters: 
      - name: image # --image
        short: i # -i
        required: true
        type: image
        fieldPaths: 
        - "spec.containers[0].image"
      - name: port # --port
        short: p # -p
        required: false
        type: int
        fieldPaths:
        - "spec.containers[0].ports[0].containerPort"
    lastCommandParam: image # so image will become the default command

[feature]Support `rudr admin:init` which will check/install oam-k8s-runtime into cluster

check K8s Cluster avaliable. (kubeconfig)
check oam-k8s-runtime is avaliable in cluster, or install it by helm.
create workloadDefinition/traitDefinition for K8s built-in resource(Deployment,StatefulSet, etc)

[feature] vela secret to manage secret for information passing

Otherwise all Secret based sensitive information pass will not work.

[feature]Provide rudr delete/uninstall command

Provide rudr delete command to clean up installed apps/components.

[Feature] show currently using env

Provide a way to show currently using env.

Or mark the currently using one in the list.

✗ rudr env
NAME     	NAMESPACE
default  	default
env-hello（*current*）	env-hello
env-world	default
test     	test

[Feature] Monitoring trait (monitoring as code)

This is input from Xiang.

We will propose a concept named "monitoring as code" after monitoring trait is ready (and installation is fully automated).
Same trait, different provider (e.g. this trait should work on Alibaba Cloud ARMS as backend besides OSS Prometheus stack).

[Feature]completion: build auto completion shell script

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

build auto completion shell script

Describe the solution you'd like

use cobra GenBashCompletion and GenZshCompletion function

Make `lastCommandParam as a subcommand and enhance corner cases

Make lastCommandParam like image as a subcommand instead of a flag.

Yes: rudr run containerized app-0709 -p 80 nginx:1.9.4.
No: rudr run containerized app-0709 -p 80 -i nginx:1.9.4

Validate whether lastCommandParam is set.

If not, prompt warnings as below.

$ rudr run containerized app-0709
You must specify `image` as the last command.
See 'rudr run -h' for help and examples

check whether all flags are set.

If not, prompt warnings as below.

$ rudr run containerized app-0709 nginx:1.9.4
Flag `port` is NOT set, please check and try again. 
See 'rudr run -h' for help and examples

[BUG] refine prompt message when switching to a not existed env

✗ rudr env:sw init
Error: open /Users/zhouzhengxi/.rudr/envs/init: no such file or directory

Refine to something like "env init doesn't exist...".

[feature] Support Appset to bundle your apps

appset init will create a directory

$ rudr appset:init myapp --tags env=prod,team=MyTeam --domain example.com
Creating at  ~/rudr/myapp/rudr.cue
SUCCESS!

$ rudr deployment:init frontend -p 80 --image resouer/demo:v1
Adding component frontend to myapp
Updating ~/rudr/myapp/frontend.cue
SUCCESS!

$ rudr route frontend --domian frontend.oam.dev
Binding route --- frontend
Updating ~/rudr/myapp/frontend.cue
SUCCESS!

$ rudr run frontend
Deploying frontend
Updating ~/rudr/myapp/rudr.cue
SUCCESS!

$ rudr delete frontend

[feature] A DSL atop OAM primitives

We can also consider support a DSL atop OAM primitives. Candidate include CUE and cdk8s.

[feature] Add Docker Compose support

Docker Compose seamless works with OAM primitives, we should consider support a Compose style rudrxFile at day 0 or day 1.

Provide available workloads in help message when executing "rudr run" or "rudr run -h"

Print all available workloads, like containerized, deployments.apps, statefulsets.apps to help user to choose one of them.

$ rudr run

You must specify a workload, like containerized, deployments.apps, statefulsets.apps
See 'rudr run -h' for help and examples

PS. In the current, there are three workloaddefinitions.

$ kubectl get workloaddefinition
NAME                                  DEFINITION-NAME
containerizedworkloads.core.oam.dev   containerizedworkloads.core.oam.dev
deployments.apps                      deployments.apps
statefulsets.apps                     statefulsets.apps

[Feature] status: get running status of your app

$ rudr status frontend
Running Status  1/1 (OK)
Workload:
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: frontend
  status:
    ...
Route:
  apiVersion: core.oam.dev/v1alpha2
  kind: Route
  metadata:
    name: frontend-xxx-trait
  status:
    ...

[feature] rudr ps

rudr ps provides overview information that the AppConfig List under namespace

$ rudr ps
NAME       workload                                      traits                                                AGE
frontend   frontend/ContainerizedWorkload                frontend/ManualScalerTrait,frontend/IngressTrait      2d
backend    backend/ContainerizedWorkload                 backend/AutoScalerTrait,backend/VolumeMounterTrait    2d

[feature] Workload should be ready to consume after run

When a Workload is created by rudr run, everything it needed as a runnable application should be configured successfully by default (could be a bunch of default trait). The result is user could open a browser to visit his app after rudr run.

[Feature] add rudr refresh to fetch all definition files locally instead of sync commands every time

I propose we add rudr refresh to fetch all definition files locally:

$ rudr refresh
~/.rudr/definitions/... updated
Currently supported comands:
  Workloads:
     - deployment
     - cloneset
  Traits:
      - route
      - tls

Then, we don't need to sync definition files every time the command is executed.

$ rudr scale myapp --replica 3
Error: we don't have command scale, try `rudr refresh` to sync all commands.

[bug] several concepts are not clearly defined

rudr workloads <- this one shows workload types (definitions), users need to do rudr components to check his workload instances.

rudr traits <- this one shows traits definitions, so we actually have no way to check existing trait instance for now.

Here are some takes:

We don't need the concept of Component in app engine, we only need Workload.
If we makerudr workloads and rudr traits show instances. Then we need to create another command to show supported types, for example:

$ rudr workload-types
$ rudr addons:workloads
$ rudr features:workloads

Prettify usage

Rudrx should be friendly to the end-users, and there are two points we should do

showing all global flags controller-runtime client need in a clean way
classify commands like kubectl or istioctl

Run workload without flags hit got panic

✗ go run main.go run containerized app2057 nginx:1.9.4
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0x1d8f012]

goroutine 1 [running]:
github.com/cloud-native-application/rudrx/pkg/cmd/run.(*runOptions).Complete(0xc000166000, 0x21e6640, 0xc000454560, 0xc000134a00, 0xc000323540, 0x2, 0x2, 0x1d2c100, 0xc0007b5d18)
	/Users/zhouzhengxi/Downloads/tmp/RudrX/pkg/cmd/run/run.go:162 +0x682
github.com/cloud-native-application/rudrx/pkg/cmd/run.NewCmdRun.func2(0xc000134a00, 0xc000323540, 0x2, 0x2)
	/Users/zhouzhengxi/Downloads/tmp/RudrX/pkg/cmd/run/run.go:104 +0x7d
github.com/spf13/cobra.(*Command).execute(0xc000134a00, 0xc0003234a0, 0x2, 0x2, 0xc000134a00, 0xc0003234a0)
	/Users/zhouzhengxi/Programming/golang/pkg/mod/github.com/spf13/[email protected]/command.go:830 +0x2aa
github.com/spf13/cobra.(*Command).ExecuteC(0xc0001ee500, 0x16219fd635a886e8, 0x2b6d6e0, 0xc000133960)
	/Users/zhouzhengxi/Programming/golang/pkg/mod/github.com/spf13/[email protected]/command.go:914 +0x2fb
github.com/spf13/cobra.(*Command).Execute(...)
	/Users/zhouzhengxi/Programming/golang/pkg/mod/github.com/spf13/[email protected]/command.go:864
main.main()
	/Users/zhouzhengxi/Downloads/tmp/RudrX/cmd/rudrx/main.go:49 +0xcd
exit status 2

[feature] support rudr plugin system discovery/install/uninstall

$ rudr plugins:config --repo https://github.com/<owner>/<repo>/<path>
$ rudr plugins:ls
NAME    		TYPE				DEFINITION              	STATUS 				APPLIES TO
scale   		trait			  hpa.autoscaling.k8s.io     installed		containerized,apps.k8s.io
ingress 		trait			  ingress.networking.k8s.io	 installed	  containerized,apps.k8s.io
deployment 	workload    deployments.apps.k8s.io		 installed
statefulset workload    statefulsets.apps.k8s.io	 uninstall
cloneset   	workload    cloneset.apps.alibaba.com  uninstall				
$ rudr plugins:install cloneset
$ rudr plugins:uninstall cloneset

Assuming we use github as repo, that will be:

# List
$ curl https://api.github.com/repos/<owner>/<repo>/contents/<path-to-dir>
[
  {
    "name": "a.yaml",
    "path": "path/a.yaml",
    "download_url": "...",
    "type": "file",
     ...
  },
  {
    "name": "b.yaml",
    "path": "path/b.yaml",
    "download_url": "...",
    "type": "file",
     ...
  }
]

# use download_url field to get the real file info
$ curl https://raw.githubusercontent.com/<owner>/<repo>/<branch>/<path-to-content>
apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: serving.knative.com
  annotations:
    short: serving
spec:
  definitionRef:
    name: serving.knative.com
  # extended fields
  extension:
    ...
    install:
      helm:
      # chart  install dependency
      -  repo: https://charts.crossplane.io/master/
         name: knative
         version: 0.0.1

Umbrella Issue for Features of CLI MVP version

Basic Usage

Advanced Usage:

support CUE as definition template file #35 @wonderflow
~~appset: bundle your apps~~ #20 （we don't support this feature in MVP）
~~snapshot: make a snapshort for your app~~ #37 （we don't support this feature in MVP）
plugins: discovery/install plugins #19 @zzxwill
dashboard: run a dashboard locally @ryanzhang-oss #154
completion: build auto completion shell script #88 @sunny0826
admin: administrator operations, like install/init #12

[Feature] support rudr env to setup k8s namespace as context

rudr env:init test --namespace test

Then all cli operations will under test namespace, untill we switch the namespace by

rudr env prod

[feature] Natively support modern CI/CD pipeline with user friendly interface.

For open source, we should support Tekton, and we should build abstraction for because Tekton is super hard to use.
For non-open source, we can support GitHub Actions.

In implementation, we could consider introduce a pipeline concept in the app engine, for example: https://devcenter.heroku.com/articles/pipelines

[BUG] env:init doesn't create namespace

✗ rudr env:init env-hello --namespace env-hello
Create env succeed, current env is env-hello

✗ rudr env env-hello
NAME     	NAMESPACE
env-hello	env-hello%           

✗ kubectl get ns | grep env-hello

[BUG] `rudr env:init test` created an environment `test` with namespace `default`

➜  /Users/zhouzhengxi/Programming/golang/src/github.com/zzxwill/RudrX git:(master) ✗ rudr env:init test
Create env succeed, current env is test
➜  /Users/zhouzhengxi/Programming/golang/src/github.com/zzxwill/RudrX git:(master) ✗ rudr env
NAME   	NAMESPACE
default	default
test   	default  %

If we can allow the names of env and namespace to be different, we should remind the user.

Binding a trait hit the issue `Operation cannot be fulfilled`

Applying trait ManualScaler to the workload of ApplicationConfiguration/Component poc07171442 hit the issue as below.

rudr bind poc07171442 ManualScaler --replicaCount 4
Applying trait for component poc07171442
Applying trait hit an issue: Operation cannot be fulfilled on applicationconfigurations.core.oam.dev "poc07171442": the object has been modified; please apply your changes to the latest version and try again

[feature] Can we use --link to model multiple components?

For now, we only support one Component one AppConfig, it should work.

Though, we could have a way to model multiple Components in same AppConfig in a "link" approach.

$ rudr run stateful mysql mysql:5.1
$ rudr run deployment frontend -p 80 --link mysql nginx:1.9.4

In this case, app engine will add frontend to the existing mysql AppConfig. Nothing else needed. /cc @wonderflow

xref: https://docs.docker.com/compose/compose-file/#links

[BUG] `%s` is appended to list commands.

%s is appended to list commands.

➜  /Users/zhouzhengxi/Programming/golang/src/github.com/zzxwill/RudrX git:(master) ✗ go run cmd/rudrx/main.go ls
NAME   	WORKLOAD             	TRAITS                    	STATUS	CREATED-TIME
app    	ContainerizedWorkload	manualscaler              	False 	2020-08-03 17:08:10 +0800 CST
poc1039	ContainerizedWorkload	poc1039-manualscaler-trait	False 	2020-08-02 10:39:54 +0800 CST
poc1447	ContainerizedWorkload	                          	True  	2020-08-03 14:48:16 +0800 CST
poc2348	ContainerizedWorkload	                          	True  	2020-08-02 23:48:20 +0800 CST%                                                                                                      ➜  /Users/zhouzhengxi/Programming/golang/src/github.com/zzxwill/RudrX git:(master) ✗ go run cmd/rudrx/main.go env

NAME   	NAMESPACE
default	default
test   	default  %

[BUG] Refine command help or prompt message

check app name is inputted for rudr

$ go run cmd/rudrx/main.go containerized:run
Error: required flag(s) "image" not set
$ go run cmd/rudrx/main.go containerized:run -image nginx:1.9.4
Creating AppConfig nginx:1.9.4
Error: create component err: Component.core.oam.dev "nginx:1.9.4" is invalid: metadata.name: Invalid value: "nginx:1.9.4": a DNS-1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

Don't ask to set flag which has default value.

$ go run cmd/rudrx/main.go manualscaler poc1039
Error: required flag(s) "replicaCount" not set

[Feature] Support rudr <workload>:run command

$ rudr deployment:run frontend --port 80 --image oam-dev/demo:v1

[BUG]Workload's complete information cannot be displayed in output fields of traits.

Description

Command "rudr traits" field "APPLIES TO" should use workload's short name. Otherwise, the workload's complete info cannot displayed.

How to reproduce

Steps to reproduce the behavior:
1 Run command "rudr traits" in terminal
2 Check command output

Expected behavior

Workload's complete information can be displayed.

Screenshots

Cluster information

Describe your kubernetes cluster information.

Kubernetes Version 1.16.6

[Feature] Consider import https://github.com/helm/helm for addon pkg mgmt

https://github.com/helm/helm is a nice lib to import rather than rely on its cli for addon pkg mgmt. Consider it.

[feature]support rudr bind/unbind trait for component

# option 2 [simple, do it first!]
$ rudr scale frontend -max=10
$ rudr scale frontend --detach

[feature] Support Job/Cloneset/serverless as built-in workload

Job => K8s job.
Cloneset => OpenKruise Clonset.
serverless => Knative Service.

Design parameters and write workloadDefinition, installation shell.

[Feature] Package mgmt should be a must have for app engine

As the title said.

The package should be discoverable by CRD and automatically installation is a must have.

If helm can be used to solve this, we use it; if it's flaw, we create our own.

[BUG] One env will be left during e2e

As we could not delete all created environments, so e2e tests will leave the env which is currently in use, as it is.