-
Notifications
You must be signed in to change notification settings - Fork 40k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strip out Status and other readonly fields from user's POST/PUT #3005
Comments
Ideally, this would be done in a generic way in the apiserver's resthandler. One idea I have is to use readonly field tags (#2970) to identify fields that should be dropped on POST/PUT. |
#1821 is a similar issue. uid is readonly. |
@nikhiljindal are you working on this? |
Not yet, AFAIK. |
Yes not working on this right now. |
I was planning to work on similar things once #3733 goes in. Also see #2726. If we drop out Status info, then we'll need to figure out how to convey status information from k8s component, e.g. controller -> apiserver (for node status), kublet -> apiserver (for pod status), etc. We probably need another endpoint, or filter based on authorization policy. The issus is marked P1, any concern for 20%er to work on it? I saw P1 should be delivered in 2 weeks.... |
I've got part of this (creates) that I'm working on. Update is harder |
@smarterclayton Any pointer to your work? so I can stand on the shoulders of giants : ) |
Going to rebase shortly, Tim had some feedback I'm trying to address. ----- Original Message -----
|
I'm in here anyway, I think I'm going to do the bare minimum and clean it up now. Will appreciate review. ----- Original Message -----
|
Finding some horrible things as I test this... as in, pod updates can change names under the covers if it hasn't been scheduled yet, you can clear PortalIP on a Service update (it looks intentional, but seems bad), and we apparently depend on some subset of the pod status info being stored in etcd. ----- Original Message -----
|
Can we chat on this tomorrow? I am currently using a Status on an object to update the status of another in #3796. I can easily make it that a spec of object A is what is used to update the status object B if we truly intend to block Status on all PUT. If we go that route, we basically always require a mirror object pattern where spec of one object is status of other. Sent from my iPhone
|
I don't think my initial changes will be as strict as described here. I think we need to reach closure among authz of updates, proper api behavior, and patterns before we fix this or introduce more status writing. Let's circle these wagons.
|
#3789 adds a framework for create that allows each type to specify its reset rules on create. We can now add a similar behavior on update. |
#4248 is the first bit of allowing PUT /status |
This is fixed |
Forked from #1370
We need to strip out Status info that users's POST/PUT. We've seen examples of users doing this, and config solutions will make it even more common to POST/PUT data returned by GET, including Status.
cc/ @bgrant0607
The text was updated successfully, but these errors were encountered: