Change:
BUG REPORT: <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version: 1.6.1 Environment: Hardware configuration: 2 identical machines, with i7-2600K CPUs and 4GB RAM. OS: CentOS 7 Kernel: 3.10.0-514.10.2.el7.x86_64 Install tools: KubeADM What happened: Deleting a deployment via the API with the DeleteOptions settings or deletes the Deployment and the replica set but NOT the pods. Deleting it with the DeleteOptions setting works as intended. What you expected to happen: The replica set deletion should propagate to the pods. I've read that the garbage collection should work for Deployments in 1.6. How to reproduce it: Anything else we need to know: I am using the and at the moment it only supports the orphanDependants option, since it's still at api version 1.5.
cc:
We discussed the problem in I'll change the GC to make sure it's cascading.
Sent
Any progress on this?
Still trying to figure out a sane fix:
I've encountered the same issue. My pods are still running even though I deleted the deployment.
lets come up with a fix for 1.7. This should work from the first time we introduced cascading deletion in Deployments.
Yes, we should. Do you have any comments on
replied. Let's move this forward. If the fix is small, I am going to backport it to 1.6.
Offline discussion with we punt this to v1.8.
Discussed with if we can get the PR fixed soon, it can still go in 1.7. It's a real bug fix.
Yes, we need to fix this for 1.7 and also backport to 1.6.
Should this be targeting 1.7?
yes, the fix that went in in is going to cause us data issues we don't want
Are you working on this? What's the timeline to resolution?
Based on above comment, looks like actually introduced a new regression. Am I right?
In , I reverted what's introduced in .
- is working on it
I approved this for 1.7 based on comment at We should revert , but are we ok with since it also introducing a new behavior. I will leave to decide.
replaces with a fix that addresses this issue systemically. While this bug did exist in 1.6.x, more things rely on GC in 1.7 than in 1.6, and without that fix, GC leaves more resources vulnerable to unintentional orphaning. Since the issue is actually with general GC behavior, should weigh in.

Discussion:
return claimed, utilerrors.NewAggregate(errlist) } <del> // AdoptReplicaSet sends a patch to take control of the ReplicaSet and also // sets the finalizers to foregroundDeletion. It returns the error if // the patching fails. </del> <ins> // AdoptReplicaSet sends a patch to take control of the ReplicaSet. It returns // the error if the patching fails. </ins> func (m *ReplicaSetControllerRefManager) AdoptReplicaSet(rs *extensions.ReplicaSet) error { if err := m.canAdopt(); err != nil { return fmt.Errorf("can't adopt ReplicaSet %v/%v (%v): %v", rs.Namespace, rs.Name, rs.UID, err)

// Note that ValidateOwnerReferences() will reject this patch if another // OwnerReference exists with controller=true. addControllerPatch := fmt.Sprintf( <del> `{ "metadata": { "ownerReferences": [{"apiVersion":"%s","kind":"%s","name":"%s","uid":"%s","controller":true,"blockOwnerDeletion":true}], "uid":"%s", "finalizers": ["foregroundDeletion"] } }`, </del> <ins> `{"metadata":{"ownerReferences":[{"apiVersion":"%s","kind":"%s","name":"%s","uid":"%s","controller":true,"blockOwnerDeletion":true}],"uid":"%s"}}`, </ins> m.controllerKind.GroupVersion(), m.controllerKind.Kind, m.controller.GetName(), m.controller.GetUID(), rs.UID) return m.rsControl.PatchReplicaSet(rs.Namespace, rs.Name, []byte(addControllerPatch))

Name:            d.Name + "-" + podTemplateSpecHash, Namespace:       d.Namespace, OwnerReferences: []metav1.OwnerReference{*newControllerRef(d)}, <del> Finalizers:      []string{metav1.FinalizerDeleteDependents}, </del> }, Spec: extensions.ReplicaSetSpec{ Replicas:        new(int32),

break } } <del> glog.V(2).Infof("at least one owner of object %s has FinalizerDeletingDependents, and the object itself has dependents, so it is going to be deleted with Foreground", item.identity) </del> <ins> glog.V(2).Infof("at least one owner of object %s has FinalizerDeletingDependents, and the object itself has dependents, so it is going to be deleted in Foreground", item.identity) </ins> // the deletion event will be observed by the graphBuilder, so the item // will be processed again in processDeletingDependentsItem. If it // doesn't have dependents, the function will remove the

default: // item doesn't have any solid owner, so it needs to be garbage // collected. Also, none of item's owners is waiting for the deletion of <del> // the dependents, so GC deletes item with Default. glog.V(2).Infof("delete object %s with Default", item.identity) return gc.deleteObject(item.identity, nil) </del> <ins> // the dependents, so set propagationPolicy based on existing finalizers. var policy metav1.DeletionPropagation switch { case hasOrphanFinalizer(latest): // if an existing orphan finalizer is already on the object, honor it. policy = metav1.DeletePropagationOrphan case hasDeleteDependentsFinalizer(latest): // if an existing foreground finalizer is already on the object, honor it. policy = metav1.DeletePropagationForeground default: // otherwise, default to background. policy = metav1.DeletePropagationBackground } glog.V(2).Infof("delete object %s with propagation policy %s", item.identity, policy) return gc.deleteObject(item.identity, &policy) </ins> } }