@lavalamp @bgrant0607, think I got the priority right

I don't think that this makes the v1.0 list.

cc @erictune @mikedanese @derekwaynecarr

@bgrant0607 - is it a backward incompatible change in your view to restrict update of RC.Status when doing an update and instead requiring to put to a /status endpoint like the rest? I began to look at that this afternoon, but worried it may be viewed as an incompatible change.

By "restrict", I assume you mean just dropping status on POST, PUT, and PATCH to the regular endpoint and only applying updates performed using the /status subresource.

It is technically a breaking change, but the RC manager isn't very pluggable at the moment, and a user would need to upgrade the apiserver and controller-manager at different times to expose a problem. A user posting to status is almost certainly accidental (e.g., kubectl get rc foo | sed | kubectl replace -f -) and would be soon overwritten by controller-manager, anyway. Additionally, it's reasonable that an admin would want to lock this down -- it's closing a DoS hole.

We should do it and write good release notes.

Ok. Will send PR Monday.

On Friday, September 25, 2015, Brian Grant notifications@github.com wrote:

By "restrict", I assume you mean just dropping status on POST, PUT, and
PATCH to the regular endpoint and only applying updates performed using the
/status subresource.

It is technically a breaking change, but the RC manager isn't very
pluggable at the moment, and a user would need to upgrade the apiserver and
controller-manager at different times to expose a problem. A user posting
to status is almost certainly accidental (e.g., kubectl get rc foo | sed
| kubectl replace -f -) and would be soon overwritten by
controller-manager, anyway. Additionally, it's reasonable that an admin
would want to lock this down -- it's closing a DoS hole.

We should do it and write good release notes.

—
Reply to this email directly or view it on GitHub
#4909 (comment)
.