The podgroup is not deleted after the pod created by Deployment is deleted
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 #1 SMP Tue May 14 21:24:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux - Install tools:
- Others:
kind is workflow runs into the same problem
For Deployment, we should create PodGroup for Deployment instead of ReplicaSet :)
Normal Pod runs into the same problem.
Thanks for the all the feedback. This fix will be merged into v1.5.0. /assign @lucming
@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.
Normal Pod runs into the same problem.
Can you give the reproduce steps? I've had a try but the performance looks good.
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!).
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!).
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! 🤗