Garbage Collect

In garbage-collect policy, there are two major capabilities you can use.

Suppose you want to keep the resources created by the old version of the application. Use the garbage-collect policy and enable the option .

1. create app

Check the status:

vela status first-vela-app --tree

expected output

CLUSTER       NAMESPACE     RESOURCE                  STATUS
local     ─── default   ─┬─ Service/express-server    updated
                         ├─ Deployment/express-server updated
                         └─ Ingress/express-server    updated

1. update the app

cat <<EOF | vela up -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: first-vela-app
spec:
  components:
    - name: express-server-1
      type: webservice
      properties:
        image: oamdev/hello-world
        port: 8000
      traits:
        - type: gateway
          properties:
            class: traefik
            domain: 47.251.8.82.nip.io
            http:
              "/": 8000
  policies:
    - name: keep-legacy-resource
      type: garbage-collect
      properties:
        keepLegacyResource: true
EOF

Check the status again:

expected output

CLUSTER       NAMESPACE     RESOURCE                    STATUS
local     ─── default   ─┬─ Service/express-server      outdated
                         ├─ Service/express-server-1    updated
                         ├─ Deployment/express-server   outdated
                         ├─ Deployment/express-server-1 updated
                         ├─ Ingress/express-server      outdated
                         └─ Ingress/express-server-1    updated

1. delete the app

$ vela delete first-vela-app

You can also persist part of the resources, which skips the normal garbage-collect process when the application is updated.

Take the following app as an example, in the garbage-collect policy, a rule is added which marks all the resources created by the expose trait to use the onAppDelete strategy. This will keep those services until application is deleted.

cat <<EOF | vela up -f -
apiVersion: core.oam.dev/v1beta1
metadata:
  name: garbage-collect-app
spec:
  components:
      type: webservice
      properties:
        image: oamdev/hello-world
      traits:
        - type: expose
          properties:
            port: [8000]
  policies:
    - name: garbage-collect
      type: garbage-collect
      properties:
        rules:
          - selector:
              traitTypes:
                - expose
            strategy: onAppDelete
EOF

You can find deployment and service created.

If you upgrade the application and use a different component, you will find the old versioned deployment is deleted but the service is kept.

cat <<EOF | vela up -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: garbage-collect-app
spec:
  components:
    - name: hello-world-new
      type: webservice
      properties:
        image: oamdev/hello-world
      traits:
        - type: expose
          properties:
            port: [8000]
  policies:
    - name: garbage-collect
      type: garbage-collect
      properties:
        rules:
          - selector:
              traitTypes:
                - expose
            strategy: onAppDelete
$ kubectl get deployment
NAME              READY   UP-TO-DATE   AVAILABLE   AGE
hello-world-new   1/1     1            1           10s
$ kubectl get service   
NAME              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
hello-world-new   ClusterIP   10.96.20.4      <none>        8000/TCP   13s

If you want to deploy job-like components, in which cases the resources in the component are not expected to be recycled even after the application is deleted, you can use the component type selector and set strategy to never as follows.

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: garbage-collect-app
spec:
  components:
    - name: hello-world-new
      type: job-like-component
  policies:
    - name: garbage-collect
      type: garbage-collect
      properties:
        rules:
          - selector:
              componentTypes:
                - webservice
            strategy: never

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: create-ns-app
spec:
  components:
    - name: example-addon-namespace
      type: k8s-objects
      properties:
        objects:
          - apiVersion: v1
            kind: Namespace
  policies:
    - name: garbage-collect
      type: garbage-collect
      properties:
        rules:
          - selector:
              componentNames:
                - example-addon-namespace
            strategy: never

If you want to garbage collect resources in the order of reverse dependency, you can add order: dependency in the garbage-collect policy.

note

This delete in order feature is only available for the resources that created in the components. Custom Resources deployed in WorkflowStep will not be included.

In the example above, component test1 depends on test2, and test2 need the output from test3.

So the creation order of deployment is: test3 -> test2 -> test1.

When we add order: dependency in policy and delete the application, the order of garbage collection is: test1 -> test2 -> test3.