Open Application Model Files

This marks the v0.3.0 release of OAM spec.

Since the last release, the spec has undergone the following major changes and improvements:

• The Application entity has been updated that its components now exposes simplified config attributes to users. Behind the scene, the ComponentDefition will be defined by platform team with the actual templating definition. In this way, it provides better separation of concerns -- it simplifies the user interfafce, and let the platform experts focus on handling the infra details.

Here is an example:

yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: my-example-app annotations: version: v1.0.0 description: "Brief description of the application" spec: components: - name: publicweb type: web-ui properties: # properties targeting component parameters. image: example/web-ui:v1.0.2@sha256:verytrustworthyhash param_1: "enabled" # param_1 is defined on the web-ui component traits: - type: ingress # ingress trait providing a public endpoint for the publicweb component of the application. properties: # properties are defined by the trait CRD spec. This example assumes path and port. path: / port: 8080 scopes: "healthscopes.core.oam.dev": "app-health" # An application level health scope including both components. - name: backend type: company/test-backend # test-backend is referenced from other namespace properties: debug: "true" # debug is a parameter defined in the test-backend component. traits: - type: scaler # scaler trait to specify the number of replicas for the backend component properties: replicas: 4 scopes: "healthscopes.core.oam.dev": "app-health" # An application level health scope including both components.

• The ComponentDefinition entity has been introduced to replace previous WorkloadDefinition. It provides CUE based schematic information which would describe the actual execution plan and expose parameters in infra-agnostic format.

Here is an example:

```yaml apiVersion: core.oam.dev/v1beta1 kind: ComponentDefinition metadata: name: webserver annotations: definition.oam.dev/description: "webserver is a combo of Deployment + Service" spec: workload: definition: apiVersion: apps/v1 kind: Deployment schematic: cue: template: | output: { apiVersion: "apps/v1" kind: "Deployment" spec: { selector: matchLabels: { "app.oam.dev/component": context.name } template: { metadata: labels: { "app.oam.dev/component": context.name } spec: { containers: [{ name: context.name image: parameter.image

                          if parameter["cmd"] != _|_ {
                              command: parameter.cmd
                          }
                          ...
                      }]
              }
              }
          }
      }
      // an extra template
      outputs: service: {
          apiVersion: "v1"
          kind:       "Service"
          spec: {
              selector: {
                  "app.oam.dev/component": context.name
              }
              ports: [
                  {
                      port:       parameter.port
                      targetPort: parameter.port
                  },
              ]
          }
      }
      parameter: {
          image: string
          cmd?: [...string]
          port: *80 | int
      }

```

• Replace Workload to Component and WorkloadDefinition to ComponentDefinition to reflect latest changes.

• The design principles has been updated to highlight runtime neutrality and separation of concerns. This is more reflected in the latest Application and ComponentDefinition changes.

• Semantic versioning has been introduced with the latest release pointed to v0.3.0, and v0.1.x and v0.2.x put into previous releases

Want to give it a try? Check out tutorials of KubeVela. Feedback is welcome!

Thanks to the contributors in this release: @dhiguero @resouer @mayocream @rhew @wonderflow @hongchaodeng @chilung @dchjmichael @pmorie @rynowak @szihai @anubhavsingh16