How to scale an application applied with AppRollout?

[Alpacius]

Initially, I've got a kubevela Application:

apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
  name: nginx-component
spec:
  workload: 
    definition: 
      apiVersion: apps/v1
      kind: Deployment
  schematic:
    kube: 
      template:
        apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: nginx-deployment
          labels:
            app: nginx
        spec:
          #replicas: 3
          selector:
            matchLabels:
              app: nginx
          template:
            metadata:
              labels:
                app: nginx
            spec:
              containers:
              - name: nginx
                image: nginx
                ports:
                - containerPort: 80
---
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: simple-application
  annotations:
    "app.oam.dev/rolling-components": "nginx-component"
    "app.oam.dev/rollout-template": "true"
    "foobar/change-made-by": "UUID-3"
spec:
  components:
  - name: nginx-component
    type: nginx-component
    properties: {}

and its corresponding AppRollout:

apiVersion: core.oam.dev/v1beta1
kind: AppRollout
metadata:
  name: rolling-example
spec:
  targetAppRevisionName: simple-application-v1
  componentList:
    - nginx-component
  rolloutPlan:
    rolloutStrategy: "IncreaseFirst"
    rolloutBatches:
      - replicas: 0
      - replicas: 1
      - replicas: 1
    targetSize: 3

The rollout went well.

jiuya.wb@ITDA-L-PF1NWRVH MINGW64 /d/aliyun-devops/temp/kubevela-examples
$ kubectl create ns jiuya-oam-demo-simple-3
namespace/jiuya-oam-demo-simple-3 created

jiuya.wb@ITDA-L-PF1NWRVH MINGW64 /d/aliyun-devops/temp/kubevela-examples
$ kubectl apply -f ./nginx-vela-kube-adhoc.yaml -n jiuya-oam-demo-simple-3
componentdefinition.core.oam.dev/nginx-component created
application.core.oam.dev/simple-application created

jiuya.wb@ITDA-L-PF1NWRVH MINGW64 /d/aliyun-devops/temp/kubevela-examples
$ kubectl apply -f ./nginx-vela-kube-adhoc-rollout.yaml -n jiuya-oam-demo-simple-3
approllout.core.oam.dev/rolling-example created

jiuya.wb@ITDA-L-PF1NWRVH MINGW64 /d/aliyun-devops/temp/kubevela-examples
$ kubectl get pods -n jiuya-oam-demo-simple-3
NAME                                 READY   STATUS              RESTARTS   AGE
nginx-component-v1-d46f5678b-p62cc   0/1     ContainerCreating   0          1s

jiuya.wb@ITDA-L-PF1NWRVH MINGW64 /d/aliyun-devops/temp/kubevela-examples
$ kubectl get pods -n jiuya-oam-demo-simple-3
NAME                                 READY   STATUS              RESTARTS   AGE
nginx-component-v1-d46f5678b-p62cc   0/1     ContainerCreating   0          9s

jiuya.wb@ITDA-L-PF1NWRVH MINGW64 /d/aliyun-devops/temp/kubevela-examples
$ kubectl get approllout -n jiuya-oam-demo-simple-3
NAME              TARGET   UPGRADED   READY   BATCH-STATE      ROLLING-STATE      AGE
rolling-example   3        1          0       batchVerifying   rollingInBatches   19s

jiuya.wb@ITDA-L-PF1NWRVH MINGW64 /d/aliyun-devops/temp/kubevela-examples
$ kubectl get approllout -n jiuya-oam-demo-simple-3
NAME              TARGET   UPGRADED   READY   BATCH-STATE   ROLLING-STATE    AGE
rolling-example   3        3          3       batchReady    rolloutSucceed   118s

Now I want to scale the replicas to 5. Since AppRollout conflicts with scaler traits and Deployment.spec.replicas in the ComponentDefinition, one viable way of invoking the scaler controller is through AppRollout:

apiVersion: core.oam.dev/v1beta1
kind: AppRollout
metadata:
  name: rolling-example
spec:
  targetAppRevisionName: simple-application-v1
  componentList:
    - nginx-component
  rolloutPlan:
    rolloutStrategy: "IncreaseFirst"
    rolloutBatches:
      #- replicas: 0
      - replicas: 1
      - replicas: 1
    targetSize: 5

However nothing has changed with the AppRollout above applied.

Is there anything wrong with those operations, or there's other workaround for scaling without generating a new apprev?

Edited: It seems this method causes the approllout controller to give up rolling out:

When we launch a rollout, the controller tries to find if there's no need to make changes:

func (r *Reconciler) DoReconcile(ctx context.Context, appRollout *v1beta1.AppRollout) (res reconcile.Result, retErr error) {
	if len(appRollout.Status.RollingState) == 0 {
		appRollout.Status.ResetStatus()
	}
	targetAppRevisionName := appRollout.Spec.TargetAppRevisionName
	sourceAppRevisionName := appRollout.Spec.SourceAppRevisionName

	// no need to proceed if rollout is already in a terminal state and there is no source/target change
	doneReconcile := r.handleRollingTerminated(*appRollout, targetAppRevisionName, sourceAppRevisionName)
	if doneReconcile {
		return reconcile.Result{}, nil
	}
        // ...

Since rollout of v1 is successful, the target revision is still v1 for scaling, and there's still no source revision, no changes need to be made. Thus the scaling is discarded silently.

[LeoLiuYan]

”Since AppRollout conflicts with scaler traits“
How to reproduce this conclusion?

[Alpacius]

Refer to: #1629 (comment)

[wangyikewxgm]

I addressed this issue.This isn't a bug, you should create a new AppRollout rather than update a existed AppRollout.I think we should tell users this in docs.

[Alpacius]

I addressed this issue.This isn't a bug, you should create a new AppRollout rather than update a existed AppRollout.I think we should tell users this in docs.

IMO it's not so friendly for platform developers to delete an associated AppRollout first, or to create a new AppRollout every time when scaling.

Is this by-design?
Just save a lastTargetSizeApplied in the status or even use last rollout size and you might tell the difference between upgrading and scaling.

[wangyikewxgm]

There is no need to delete, creating a new one is enough. A failed/succeed rollout is like an operation recode, and will not cause any effects for workload. you could update AppRollout when you want update AppRollout in middle of one rollout process like pause/batchPartition, otherwise you always shouldn't update a AppRollout