update oam definition protocal
Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com>
This commit is contained in:
Jianbo Sun
parent
daa6a44689
commit
9459ae4d19
|
|
@ -47,7 +47,7 @@ services:
|
|||
build:
|
||||
docker:
|
||||
file: Dockerfile
|
||||
contrxt: .
|
||||
context: .
|
||||
cmd: ["node", "server.js"]
|
||||
port: 8080
|
||||
cpu: "0.01"
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Definition Protocol
|
||||
title: OAM Definition Protocol
|
||||
---
|
||||
|
||||
KubeVela is fully programmable via [CUE](https://cuelang.org), while it leverage Kubernetes as control plane and align with the API in yaml.
|
||||
|
|
@ -266,7 +266,42 @@ This field defines the field path of the trait which is used to store the refere
|
|||
|
||||
If this field is set, KubeVela core will automatically fill the workload reference into target field of the trait. Then the trait controller can get the workload reference from the trait latter. So this field usually accompanies with the traits whose controllers relying on the workload reference at runtime.
|
||||
|
||||
Please check [scaler](https://github.com/kubevela/kubevela/blob/master/charts/vela-core/templates/defwithtemplate/scaler.yaml) trait as a demonstration of how to set this field.
|
||||
For example, when this field set in the following custom trait:
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: TraitDefinition
|
||||
metadata:
|
||||
name: myscaler
|
||||
spec:
|
||||
workloadRefPath: spec.workloadRef
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
outputs: scaler: {
|
||||
apiVersion: "core.oam.dev/v1alpha2"
|
||||
kind: "ManualScalerTrait"
|
||||
spec: {
|
||||
replicaCount: parameter.replicas
|
||||
}
|
||||
}
|
||||
parameter: {
|
||||
//+short=r
|
||||
//+usage=Replicas of the workload
|
||||
replicas: *1 | int
|
||||
}
|
||||
```
|
||||
|
||||
The controller will automatically inject the apiVersion/Kind/Name of the workload defined in the component into the field specified in `workloadRefPath`, the result of the trait object in the app can be something like below, assume the workload is a Kubernetes Deployment:
|
||||
```yaml
|
||||
apiVersion: "core.oam.dev/v1alpha2"
|
||||
kind: "ManualScalerTrait"
|
||||
spec:
|
||||
workloadRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: mywork
|
||||
replicaCount: 1
|
||||
```
|
||||
|
||||
### `.spec.podDisruptive`
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Definition Protocol
|
||||
title: OAM Definition Protocol
|
||||
---
|
||||
|
||||
KubeVela is fully programmable via [CUE](https://cuelang.org), while it leverage Kubernetes as control plane and align with the API in yaml.
|
||||
|
|
@ -266,7 +266,42 @@ This field defines the field path of the trait which is used to store the refere
|
|||
|
||||
If this field is set, KubeVela core will automatically fill the workload reference into target field of the trait. Then the trait controller can get the workload reference from the trait latter. So this field usually accompanies with the traits whose controllers relying on the workload reference at runtime.
|
||||
|
||||
Please check [scaler](https://github.com/kubevela/kubevela/blob/master/charts/vela-core/templates/defwithtemplate/scaler.yaml) trait as a demonstration of how to set this field.
|
||||
For example, when this field set in the following custom trait:
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: TraitDefinition
|
||||
metadata:
|
||||
name: myscaler
|
||||
spec:
|
||||
workloadRefPath: spec.workloadRef
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
outputs: scaler: {
|
||||
apiVersion: "core.oam.dev/v1alpha2"
|
||||
kind: "ManualScalerTrait"
|
||||
spec: {
|
||||
replicaCount: parameter.replicas
|
||||
}
|
||||
}
|
||||
parameter: {
|
||||
//+short=r
|
||||
//+usage=Replicas of the workload
|
||||
replicas: *1 | int
|
||||
}
|
||||
```
|
||||
|
||||
The controller will automatically inject the apiVersion/Kind/Name of the workload defined in the component into the field specified in `workloadRefPath`, the result of the trait object in the app can be something like below, assume the workload is a Kubernetes Deployment:
|
||||
```yaml
|
||||
apiVersion: "core.oam.dev/v1alpha2"
|
||||
kind: "ManualScalerTrait"
|
||||
spec:
|
||||
workloadRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: mywork
|
||||
replicaCount: 1
|
||||
```
|
||||
|
||||
### `.spec.podDisruptive`
|
||||
|
||||
|
|
|
|||
|
|
@ -51,9 +51,9 @@ To enable the addon suites, you simply needs to run the `vela addon enable` comm
|
|||
|
||||
Now you can access your grafana by access `http://localhost:8080` in your browser. The default username and password are `admin` and `kubevela` respectively.
|
||||
|
||||
## Internal Dashboards
|
||||
## Automated Dashboards
|
||||
|
||||
There are four internal dashboards you can navigate and view your system.
|
||||
There are four automated dashboards you can navigate and view your system.
|
||||
|
||||
### KubeVela Application
|
||||
|
||||
|
|
@ -341,6 +341,10 @@ Now you can manage your dashboard and datasource on your grafana instance throug
|
|||
|
||||
For more details, you can refer to [vela-prism](https://github.com/kubevela/prism#grafana-related-apis).
|
||||
|
||||
### Integrate Other Tools or Systems
|
||||
|
||||
There are a wide range of community tools or eco-systems that users can leverage for building their observability system, such as prometheus-operator or DataDog. By far, KubeVela does not have existing best practices for those integration. We may integrate with those popular projects through KubeVela addons in the future. We are also welcome to community contributions for broader explorations and more connections.
|
||||
|
||||
## Comparisons
|
||||
|
||||
### Compared with Helm
|
||||
|
|
|
|||
Loading…
Reference in New Issue