improve: continue allocating if remain tasks is more than job's minMember

[lowang-bh]

As PR #1459 has supported minAvailable at task level.

#3057 has improved and fixed the minResource calculation for a volcano job.
This PR continue to improve and fix the scheduling.

Consider this scene:
part of pods of a job is not schedulable, and left pods are schedulable, and the number can meet up the condition of min member.
example: cluster has only 4GPU and enough CP/MEM, a job with 1ps + 8worker, each worker request 1GPU and has higher priority than ps. So workers will be scheduled first and failed at 5th worker. After that, job will be failed scheduling and break out from allocate.

So this pr fix this issue: if allocated pod less than minMember and tasks are not used up, will continue on, untill the number of remained tasks can not meet up the condition of min member

commit 1: continue allocating and testcases about the feature change
commit 2: use string type to replace the taskID type, which indicate a role spec of each task in a job
commit 3: consider job's each task's min member when check if it can continue on allocating
commit 4: parse and store task spec in taskInfo, so that it doesn't need to parse it everywhere and whenerver it is used.
And add pre-check if task has fit error so as to save predicating time and avoid the useless computing. Testing with a 100master+100worker job has no obvious latancy comparing without this PR.

An Example Yaml Without Priority setting

with the following job yaml on a cluster with available CPU=10

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: job5
spec:
  schedulerName: volcano
  minAvailable: 3
  queue: default
  tasks:
    - replicas: 2
      minAvailable: 1
      name: "master"
      template:
        spec:
          containers:
            - image: nginx:latest
              name: nginx
              resources:
                requests:
                  cpu: "4"
                  memory: "50Mi"
          restartPolicy: OnFailure
    - replicas: 2
      minAvailable: 2
      name: "work"
      template:
        spec:
          containers:
            - image: nginx:latest
              name: nginx
              resources:
                requests:
                  cpu: "3"
                  memory: "100Mi"
          restartPolicy: OnFailure

Test Example Yaml

with the following job yaml on a cluster with available CPU<4

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  name: my-apps
spec:
  schedulerName: volcano
  minAvailable: 2
  tasks:
    - replicas: 2
      name: "web"
      minAvailable: 1
      template:
        spec:
          containers:
            - image: nginx:1.14.2
              name: web
              resources:
                requests:
                  cpu: "1000m"
                  memory: "100Mi"
          restartPolicy: OnFailure
    - replicas: 2
      minAvailable: 1
      name: "server"
      template:
        spec:
          containers:
            - image: nginx:1.14.2
              name: server
              resources:
                requests:
                  cpu: "2000m"
                  memory: "100Mi"
          restartPolicy: OnFailure
          priorityClassName: high-priority

without this pr on master branch

with this pr

[lowang-bh]

/assign @Monokaix @hwdef @william-wang

[hwdef]

It looks like this PR does two things. But use one commit

[lowang-bh]

It looks like this PR does two things. But use one commit

Have splited them into two commits.

[lowang-bh]

@Monokaix @hwdef @wangyang0616 @william-wang please help to review it. thanks.

[hwdef]

I think the others are fine

[Monokaix]

The are 4 commits but the description has 2 commit.

[Monokaix]

A little doubt, in what case will a work pod has higher priority than ps? And what if pods in a vcjob have the same priority?

[lowang-bh]

A little doubt, in what case will a work pod has higher priority than ps? And what if pods in a vcjob have the same priority?

worker with GPU request, can have a higher priority, so as to allocate gpu pod first.

[lowang-bh]

And what if pods in a vcjob have the same priority?

With no priority setting, the task order will be default compare stragety at

volcano/pkg/controllers/job/helpers/helpers.go

Lines 51 to 66 in 3483685

	func CompareTask(lv, rv *api.TaskInfo) bool {
	lStr := GetPodIndexUnderTask(lv.Pod)
	rStr := GetPodIndexUnderTask(rv.Pod)
	lIndex, lErr := strconv.Atoi(lStr)
	rIndex, rErr := strconv.Atoi(rStr)
	if lErr != nil || rErr != nil || lIndex == rIndex {
	if lv.Pod.CreationTimestamp.Equal(&rv.Pod.CreationTimestamp) {
	return lv.UID < rv.UID
	}
	return lv.Pod.CreationTimestamp.Before(&rv.Pod.CreationTimestamp)
	}
	if lIndex > rIndex {
	return false
	}
	return true
	}

With Given Example Yaml Without Priority setting

before

after this pr

[Monokaix]

/lgtm

[hwdef]

/lgtm

[william-wang]

/approve

[volcano-sh-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: william-wang

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

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/scheduler/OWNERS [william-wang]

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