CloneSet scale down schedule-failed pods firstly

[veophi]

Ⅰ. Describe what this PR does

In the scene:

replicas: 20
partition: 10

current-revision:
   runningPods: 5
   scheduleFailedPods: 5
update-revision:
   runningPods: 5
   scheduleFailedPods: 5

when scaling down CloneSet from 20 to 10, we hope that 10 running Pods are reserved. Howerver, 10 current-revision pods will be reserved in current kruise version.

Ⅱ. Does this pull request fix one issue?

Ⅲ. Describe how to verify it

Ⅳ. Special notes for reviews

[kruise-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from veophi by writing /assign @veophi in a comment. For more information see:The Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[furykerry]

if the partition is 50%, then it is reasonable to keep 10 running pods. However if the partition is absolute value, keeping 10 running pods will break the semantic meaning of partition. Is it ok for you to change the partition to percent form?

[veophi]

if the partition is 50%, then it is reasonable to keep 10 running pods. However if the partition is absolute value, keeping 10 running pods will break the semantic meaning of partition. Is it ok for you to change the partition to percent form?

replicas: 20
partition: 50%

current-revision:
   runningPods: 3
   scheduleFailedPods: 7
update-revision:
   runningPods: 7
   scheduleFailedPods: 3

[codecov]

Codecov Report

Attention: Patch coverage is 41.17647% with 20 lines in your changes are missing coverage. Please review.

Project coverage is 49.19%. Comparing base (3b7c731) to head (344c29e).
Report is 12 commits behind head on master.

Files	Patch %	Lines
pkg/controller/cloneset/utils/cloneset_utils.go	0.00%	20 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1515      +/-   ##
==========================================
- Coverage   49.21%   49.19%   -0.03%     
==========================================
  Files         157      157              
  Lines       22604    22634      +30     
==========================================
+ Hits        11125    11135      +10     
- Misses      10268    10288      +20     
  Partials     1211     1211              

Flag	Coverage Δ
unittests	49.19% <41.17%> (-0.03%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kruise-bot]

@veophi: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[Spground]

However if the partition is absolute value, keeping 10 running pods

Why not upgra partition is absolute value,

if the partition is 50%, then it is reasonable to keep 10 running pods. However if the partition is absolute value, keeping 10 running pods will break the semantic meaning of partition. Is it ok for you to change the partition to percent form?

replicas: 20
partition: 50%

current-revision:
   runningPods: 3
   scheduleFailedPods: 7
update-revision:
   runningPods: 7
   scheduleFailedPods: 3

Will extra 2 upgraded Pods rollback to current revision if we prefer scale down failed Pod?