Issue 1:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.):

No

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.):

finalizer

orphan

Is this a BUG REPORT or FEATURE REQUEST? (choose one):

Bug Report

Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.3", GitCommit:"c6411395e09da356c608896d3d9725acab821418", GitTreeState:"clean", BuildDate:"2016-07-22T20:29:38Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"darwin/amd64"}

Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.5+coreos.0", GitCommit:"f70c2e5b2944cb5d622621a706bdec3d8a5a9c5e", GitTreeState:"clean", BuildDate:"2016-10-31T19:16:47Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}

Environment:

Cloud provider or hardware configuration: CoreOS Tectonic on AWS

OS (e.g. from /etc/os-release): CoreOS stable (1185.3.0)

Kernel (e.g. uname -a): Linux ip-10-0-0-50.us-west-1.compute.internal 4.7.3-coreos-r2 #1 SMP Tue Nov 1 01:38:43 UTC 2016 x86_64 Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz GenuineIntel GNU/Linux

Install tools: CoreOS Tectonic Installer (self-hosted cluster)

Others:

What happened:

When deleting a ReplicaSet, the orphan parameter is populated, but the pods are never removed, blocking the RS from being deleted.

What you expected to happen:

RS is deleted

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

Create a RS and attempt to delete it from either the UI or kubectl.

Create RS and spin up pods

Delete the RS

Delete will succeed, but the object will never disappear. The orphan parameter is applied to the object.

With kubectl edit, removing the orphan parameter will result in successful deletion.

Anything else do we need to know:

The Tectonic Console issues delete requests with orphanDependents=false. It seems like the orphan component is not running at all. I'm not sure where to best debug that or in which control loop it runs.

Issue 2:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.): No

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): panic thirdpartyresourcedata

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT

Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.0", GitCommit:"a16c0a7f71a6f93c7e0f222d961f4675cd97a46b", GitTreeState:"clean", BuildDate:"2016-09-26T18:16:57Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.0+coreos.0", GitCommit:"278a1f7034bdba61cba443722647da1a8204a6fc", GitTreeState:"clean", BuildDate:"2016-09-26T20:48:37Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}

Also present in current master

What happened:

As part of attempt to support third party resources in helm/helm#1295, I've found that the default client attempts a weird patch behaviour:

PATCH /apis/stable.k8s.psg.io/v1/namespaces/hello-world/certificates/hello-world HTTP/1.1
Host: localhost:8080
User-Agent: tiller/v1.4.1 (linux/amd64) kubernetes/$Format
Content-Length: 388
Accept: application/json, */*
Content-Type: application/strategic-merge-patch+json
Accept-Encoding: gzip

{"data":"eyJhcGlWZXJzaW9uIjoic3RhYmxlLms4cy5wc2cuaW8vdjEiLCJraW5kIjoiQ2VydGlmaWNhdGUiLCJtZXRhZGF0YSI6eyJuYW1lIjoiaGVsbG8td29ybGQifSwic3BlYyI6eyJkb21haW4iOiJoZWxsby13b3JsZC5rOHMuZXUtd2VzdC0xLmF3cy5zaGQuZGV2Lmxhc3RtaWxlLmNvbSIsImVtYWlsIjoibStoZWxsby13b3JsZEBvY2Fkby5jb20iLCJwcm92aWRlciI6InJvdXRlNTMifX0=","kind":"ThirdPartyResourceData","metadata":{"labels":null},"spec":null,"status":null}

This causes kube-apiserver to panic:

I1010 16:04:50.014030 1 handlers.go:162] GET /apis/stable.k8s.psg.io/v1/namespaces/hello-world/certificates/hello-world: (1.486244ms) 200 [[tiller/v1.4.1 (linux/amd64) kubernetes/$Format] 127.0.0.1:53188]
E1010 16:04:50.033872 1 runtime.go:64] Observed a panic: "invalid memory address or nil pointer dereference" (runtime error: invalid memory address or nil pointer dereference)
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/util/runtime/runtime.go:70
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/util/runtime/runtime.go:63
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/util/runtime/runtime.go:49
/usr/local/go/src/runtime/asm_amd64.s:472
/usr/local/go/src/runtime/panic.go:443
/usr/local/go/src/runtime/panic.go:62
/usr/local/go/src/runtime/sigpanic_unix.go:24
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/registry/thirdpartyresourcedata/codec.go:421
<autogenerated>:5
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/runtime/codec.go:60
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/apiserver/resthandler.go:573
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/api/rest/update.go:177
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/registry/generic/registry/store.go:355
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/storage/etcd/etcd_helper.go:462
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/registry/generic/registry/store.go:431
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/apiserver/resthandler.go:645
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/apiserver/resthandler.go:953
/usr/local/go/src/runtime/asm_amd64.s:1998
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x15e2192]

goroutine 1212 [running]:
panic(0x4475c00, 0xc820016070)
/usr/local/go/src/runtime/panic.go:481 +0x3e6
k8s.io/kubernetes/pkg/util/runtime.HandleCrash(0xc8223d3ef8, 0x1, 0x1)
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/util/runtime/runtime.go:56 +0x153
panic(0x4475c00, 0xc820016070)
/usr/local/go/src/runtime/panic.go:443 +0x4e9
k8s.io/kubernetes/pkg/registry/thirdpartyresourcedata.(*thirdPartyResourceDataDecoder).Decode(0xc821509740, 0xc821735880, 0x223, 0x35c, 0x0, 0x7fbdf5c06130, 0xc822bdc480, 0x0, 0x0, 0x10739d9, ...)
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/registry/thirdpartyresourcedata/codec.go:421 +0x1dc2
k8s.io/kubernetes/pkg/runtime.(*codec).Decode(0xc821509760, 0xc821735880, 0x223, 0x35c, 0x0, 0x7fbdf5c06130, 0xc822bdc480, 0x0, 0x0, 0xc8226a2900, ...)
<autogenerated>:5 +0xca
k8s.io/kubernetes/pkg/runtime.DecodeInto(0x7fbdf5bc4f88, 0xc821509760, 0xc821735880, 0x223, 0x35c, 0x7fbdf5c06130, 0xc822bdc480, 0x0, 0x0)
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/runtime/codec.go:60 +0x98
k8s.io/kubernetes/pkg/apiserver.patchResource.func1(0x7fbdf5c46f90, 0xc822ba05d0, 0x0, 0x0, 0x7fbdf5c06130, 0xc822ed5680, 0x0, 0x0, 0x0, 0x0)
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/apiserver/resthandler.go:573 +0x11f7
k8s.io/kubernetes/pkg/api/rest.(*defaultUpdatedObjectInfo).UpdatedObject(0xc822ba6240, 0x7fbdf5c46f90, 0xc822ba05d0, 0x7fbdf5c06130, 0xc822ed5680, 0x0, 0x0, 0x0, 0x0)
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/api/rest/update.go:177 +0x1aa
k8s.io/kubernetes/pkg/registry/generic/registry.(*Store).Update.func1(0x7fbdf5c06130, 0xc822ed5680, 0x0, 0x57846d, 0x0, 0x0, 0x0, 0x0, 0x0)
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/registry/generic/registry/store.go:355 +0x10d
k8s.io/kubernetes/pkg/storage/etcd.(*etcdHelper).GuaranteedUpdate(0xc8201cd700, 0x7fbdf5c46f50, 0xc822ba05d0, 0xc822ba2ae0, 0x57, 0x7fbdf5c06130, 0xc822ed5560, 0x1, 0xc820028af8, 0xc822bcc000, ...)
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/storage/etcd/etcd_helper.go:462 +0x49e
k8s.io/kubernetes/pkg/registry/generic/registry.(*Store).Update(0xc82018b5e0, 0x7fbdf5c46f90, 0xc822ba05d0, 0xc822ba2645, 0xb, 0x7fbdf5bd9b70, 0xc822ba6240, 0x0, 0x0, 0x40a100, ...)
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/registry/generic/registry/store.go:431 +0x401
k8s.io/kubernetes/pkg/apiserver.patchResource.func3(0x0, 0x0, 0x0, 0x0)
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/apiserver/resthandler.go:645 +0xda
k8s.io/kubernetes/pkg/apiserver.finishRequest.func1(0xc822ba2900, 0xc822ea88c0, 0xc822ba28a0, 0xc822ba2840)
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/apiserver/resthandler.go:953 +0xd9
created by k8s.io/kubernetes/pkg/apiserver.finishRequest
/go/src/k8s.io/kubernetes/_output/dockerized/go/src/k8s.io/kubernetes/pkg/apiserver/resthandler.go:958 +0xf1
m@hotcpc17686:/export/home/m/go/src/k8s.io/kubernetes$

What you expected to happen:

No panic. I suspect this behaviour shouldn't work anyway, but it should return an error rather than letting a user crash the apiserver at-will.

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

Use a third party resource such as the Certificate one from https://github.com/PalmStoneGames/kube-cert-manager

Create a resource

Patch it with something like the following:

{"data":"eyJhcGlWZXJzaW9uIjoic3RhYmxlLms4cy5wc2cuaW8vdjEiLCJraW5kIjoiQ2VydGlmaWNhdGUiLCJtZXRhZGF0YSI6eyJuYW1lIjoiaGVsbG8td29ybGQifSwic3BlYyI6eyJkb21haW4iOiJoZWxsby13b3JsZC5rOHMuZXUtd2VzdC0xLmF3cy5zaGQuZGV2Lmxhc3RtaWxlLmNvbSIsImVtYWlsIjoibStoZWxsby13b3JsZEBvY2Fkby5jb20iLCJwcm92aWRlciI6InJvdXRlNTMifX0="
,"kind":"ThirdPartyResourceData"}

Anything else do we need to know:

PR to follow with a test case, no fix yet