Skip to content
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

High-level guidance about what types of updates to use in what scenario #3153

Closed
abonas opened this issue Dec 29, 2014 · 6 comments
Closed
Assignees
Labels
area/api Indicates an issue on api area. area/usability kind/documentation Categorizes issue or PR as related to documentation. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery.
Milestone

Comments

@abonas
Copy link
Contributor

abonas commented Dec 29, 2014

There's a lack of documentation and examples of use cases - when the entities should be updated, and which fields are updatable.
For example, can a port of a service be updated? replicas number of a rep.controller be reduced? containers section of a pod changed to have another containers than the original?

@smarterclayton smarterclayton added the kind/documentation Categorizes issue or PR as related to documentation. label Dec 29, 2014
@smarterclayton
Copy link
Contributor

it would be ideal if this was called out in the api doc generated by swagger - I believe that was proposed here #2282 but not yet implemented

@abonas
Copy link
Contributor Author

abonas commented Jan 5, 2015

@smarterclayton , generating means it's supposed to be documented somewhere, right? So any docs/explanation here regarding update concept will be beneficial.

@goltermann goltermann added the priority/backlog Higher priority than priority/awaiting-more-evidence. label Jan 7, 2015
@bgrant0607 bgrant0607 added area/api Indicates an issue on api area. area/usability labels Jan 8, 2015
@bgrant0607
Copy link
Member

Proposal to tag readonly fields: #2970.

Yes, we should also document which fields cannot be updated -- most can. I'd also use tags that could be converted to some kind of properties exposed via swagger for that.

@bgrant0607 bgrant0607 added the sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. label Feb 5, 2015
@bgrant0607 bgrant0607 modified the milestones: v1.0, Doc Fixit Feb 6, 2015
@bgrant0607
Copy link
Member

Let's use #1728 for which fields can be updated and which ones can't.

#3112 is for documenting PUT semantics.

#3086 is for documenting use of resourceVersion in PUT and /watch.

This issue should be for providing high-level guidance about what flavor of update to use in what situation. Also, since most users will use kubectl, we should start with docs in terms of kubectl. When to use kubectl update, --patch, rollingupdate, resize, label, delete/create, etc.

@bgrant0607 bgrant0607 changed the title Document the update flow - when entities should be updated and which fields High-level guidance about what types of updates to use in what scenario Mar 5, 2015
@bgrant0607 bgrant0607 removed this from the Doc Fixit milestone Mar 30, 2015
@bgrant0607 bgrant0607 added this to the v1.0 milestone Jun 20, 2015
@bgrant0607 bgrant0607 added priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. and removed priority/backlog Higher priority than priority/awaiting-more-evidence. labels Jun 25, 2015
@bgrant0607 bgrant0607 self-assigned this Jul 7, 2015
@bgrant0607
Copy link
Member

There is some guidance here:
#1702 (comment)

@bgrant0607
Copy link
Member

Fixed by #11071

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api Indicates an issue on api area. area/usability kind/documentation Categorizes issue or PR as related to documentation. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery.
Projects
None yet
Development

No branches or pull requests

5 participants