The podgroup is not deleted after the pod created by Deployment is deleted

[hansongChina]

What happened:
When changing Deployment triggers the creation of a new ReplicaSet and the pod created by the old ReplicaSet is deleted, the podgroup of the old pod is not deleted

What you expected to happen:

the podgroup of the old pod is deleted

How to reproduce it (as minimally and precisely as possible):

• step1:Add the default volcano to pod using admission Webhooks, for example

patches = append(patches, patchOperation{ Op: "add", Path: "/spec/schedulerName", Value: "volcano", })

• step2:Create a Deployment,for example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

kubectl apply -f nginx-deployment.yaml

kubectl edit pod nginx-deployment-6b474476c4-v6k4x

kubectl edit pg  podgroup-6f08b2ae-296e-43a1-825c-84e483c3ea89

• step3: Modify "image:nginx:1.14.2" in Deployment to trigger the creation of a new RS and a new POD. The old pod is deleted and the podgroup associated with the old POD still exists in the state of inqueue
  

kubectl edit pg  podgroup-6f08b2ae-296e-43a1-825c-84e483c3ea89

Anything else we need to know?:

kind is workflow runs into the same problem

Environment:

• Volcano Version: v1.4.0

• Kubernetes version (use kubectl version):
  Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.9", GitCommit:"94f372e501c973a7fa9eb40ec9ebd2fe7ca69848", GitTreeState:"clean", BuildDate:"2020-09-16T13:56:40Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}
  Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.9", GitCommit:"94f372e501c973a7fa9eb40ec9ebd2fe7ca69848", GitTreeState:"clean", BuildDate:"2020-09-16T13:47:43Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}

• Cloud provider or hardware configuration:
  
  

• OS (e.g. from /etc/os-release):
  NAME="CentOS Linux"
  VERSION="7 (Core)"
  ID="centos"
  ID_LIKE="rhel fedora"
  VERSION_ID="7"
  PRETTY_NAME="CentOS Linux 7 (Core)"
  ANSI_COLOR="0;31"
  CPE_NAME="cpe:/o:centos:centos:7"
  HOME_URL="https://www.centos.org/"
  BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

• Kernel (e.g. uname -a):
  Linux 3.10.0-957.12.2.el7.x86_64 Rename hpw.cloud keyword to volcano.sh #1 SMP Tue May 14 21:24:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
• Install tools:
• Others:

[hansongChina]

kind is workflow runs into the same problem

[k82cn]

For Deployment, we should create PodGroup for Deployment instead of ReplicaSet :)

[D0m021ng]

Normal Pod runs into the same problem.

[Thor-wl]

Thanks for the all the feedback. This fix will be merged into v1.5.0.
/assign @lucming

[volcano-sh-bot]

@Thor-wl: GitHub didn't allow me to assign the following users: lucming.

Note that only volcano-sh members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

Thanks for the all the feedback. This fix will be merged into v1.5.0.
/assign @lucming

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.

[Thor-wl]

Normal Pod runs into the same problem.

Can you give the reproduce steps? I've had a try but the performance looks good.

[stale]

Hello 👋 Looks like there was no activity on this issue for last 90 days.
Do you mind updating us on the status? Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity for 60 days, this issue will be closed (we can always reopen an issue if we need!).

[stale]

Hello 👋 Looks like there was no activity on this issue for last 90 days.
Do you mind updating us on the status? Is this still reproducible or needed? If yes, just comment on this PR or push a commit. Thanks! 🤗
If there will be no activity for 60 days, this issue will be closed (we can always reopen an issue if we need!).

[stale]

Closing for now as there was no activity for last 60 days after marked as stale, let us know if you need this to be reopened! 🤗