Server-side Apply

[apelisse]

Feature Description

• One-line feature description (can be used as a release note): Move "apply" and declarative object management from kubectl to the apiserver in order to fix many of the existing bugs that we can't fix today. Also use that opportunity to add "field ownership".
• Primary contact (assignee): @apelisse @lavalamp
• Responsible SIGs: sig-api-machinery sig-cli (wg-apply was created for that purpose).
• Design proposal link (community repo): https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/555-server-side-apply
• Link to e2e and/or unit tests:
  • Unit-tests:
  • https://github.com/kubernetes-sigs/structured-merge-diff/blob/master/typed/merge_test.go
  • https://github.com/kubernetes-sigs/structured-merge-diff/blob/master/typed/deduced_test.go
  • https://github.com/kubernetes-sigs/structured-merge-diff/blob/master/typed/symdiff_test.go
  • https://github.com/kubernetes-sigs/structured-merge-diff/blob/master/typed/toset_test.go
  • https://github.com/kubernetes-sigs/structured-merge-diff/blob/master/typed/validate_test.go
  • https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/pkg/endpoints/handlers/fieldmanager/fieldmanager_test.go
  • Integration tests:
  • https://github.com/kubernetes/kubernetes/blob/master/test/cmd/apply.sh
  • https://github.com/kubernetes/kubernetes/blob/master/test/integration/apiserver/apply/apply_test.go
  • https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiextensions-apiserver/test/integration/apply_test.go
• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @lavalamp @pwittrock @erictune
• Approver (likely from SIG/area to which feature belongs): @bgrant0607
• Feature target (which target equals to which milestone):
  • Alpha release target (x.y) 1.14
  • Beta release target (x.y) 1.15
  • Stable release target (x.y) 1.21

[idvoretskyi]

/assign @apelisse

[zparnold]

Looks like we still need some docs to get this feature ready for release @apelisse Could I please get some help with that? If there’s anything I can do to assist please let me know

At a minimum we're looking to have a placeholder PR on the kubernetes/website repo. The process is fairly straightforward: checkout release-1.11 branch, make a placeholder commit, push it to your fork, and raise a PR between it and the release-1.11 branch, with /hold status.

THANKS SO MUCH!!!!!

[justaugustus]

@apelisse I noticed the milestone change. Are you planning on pulling this from the 1.11 release?

[apelisse]

Yeah, not in 1.11. I'm updating the body.

[justaugustus]

Thanks @apelisse!

[kwiesmueller]

Unsure if it is the right place to comment about this, but we have been working on our own kind of "server side apply" by building https://github.com/seibert-media/dimios While this is solely a slack time project which we hope to build our future interaction with Kubernetes on, we both stumbled into problems with the entire apply process (discussed on slack with some people) but also did some thinking on how to best approach this.

While I haven't worked on K8s directly myself yet, I could imagine to contribute to this idea/feature if possible/wanted.

[apelisse]

Can you send this as an email to kubernetes-wg-apply@googlegroups.com? We can follow-up there.

[kwiesmueller]

@apelisse I am not allowed to post messages to said group (kwiesmueller@seibert-media.net)

[apelisse]

Sorry, you may need to join the group first: https://groups.google.com/forum/#!forum/kubernetes-wg-apply

Blue button, "Join group to post" (top left)

[justaugustus]

@apelisse @kubernetes/sig-api-machinery-feature-requests @kubernetes/sig-cli-feature-requests --

This feature was removed from the previous milestone, so we'd like to check in and see if there are any plans for this in Kubernetes 1.12.

If so, please ensure that this issue is up-to-date with ALL of the following information:

• One-line feature description (can be used as a release note):
• Primary contact (assignee):
• Responsible SIGs:
• Design proposal link (community repo):
• Link to e2e and/or unit tests:
• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
• Approver (likely from SIG/area to which feature belongs):
• Feature target (which target equals to which milestone):
  • Alpha release target (x.y)
  • Beta release target (x.y)
  • Stable release target (x.y)

Set the following:

• Description
• Assignee(s)
• Labels:
  • stage/{alpha,beta,stable}
  • sig/*
  • kind/feature

Please note that the Features Freeze is July 31st, after which any incomplete Feature issues will require an Exception request to be accepted into the milestone.

In addition, please be aware of the following relevant deadlines:

• Docs deadline (open placeholder PRs): 8/21
• Test case freeze: 8/28

Please make sure all PRs for features have relevant release notes included as well.

Happy shipping!

/cc @justaugustus @kacole2 @robertsandoval @rajendar38

[apelisse]

I think everything is there @justaugustus! Thank you

[justaugustus]

Thanks for the update, @apelisse!

[zparnold]

Hey there! @apelisse I'm the wrangler for the Docs this release. Is there any chance I could have you open up a docs PR against the release-1.12 branch as a placeholder? That gives us more confidence in the feature shipping in this release and gives me something to work with when we start doing reviews/edits. Thanks! If this feature does not require docs, could you please update the features tracking spreadsheet to reflect it?

[apelisse]

@zparnold Changed the milestone from 1.12 to 1.13 :-). You can forget about this for now, thanks.

[lavalamp]

It'll be alpha, it would be good to document. Jenny said she'd try and put something together. [EDIT: wrong issue, ignore]

On Tue, Aug 21, 2018 at 12:44 PM Antoine Pelisse notifications@github.com wrote:

@zparnold https://github.com/zparnold Changed the milestone from 1.12 to 1.13 :-). You can forget about this for now, thanks.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes/features/issues/555#issuecomment-414797736, or mute the thread https://github.com/notifications/unsubscribe-auth/AAnglgxXgV0DuPpOq4P4UZZjMY8Fcx6Lks5uTGMDgaJpZM4TKb_j .

[lavalamp]

Sorry, I saw this in my email and mistook it for the dry run feature issue. Yes, serverside apply is not launching in 1.12.

[kacole2]

@lavalamp @apelisse I'll make the changes in the spreadsheet. thanks for making us aware! cc @justaugustus

[spiffxp]

Are there any issues or PR's we could track to better understand what work is being done to land what functionality in 1.13 as part of this?

[apelisse]

@spiffxp We don't have an issue right now. we have a working-group for this, and we keep track of tasks in a spreadsheet. I'll try to create an issue to track the progress and increase visibility, thank you.

[lavalamp]

Isn't this the issue?

For PRs, look here: https://github.com/kubernetes-sigs/structured-merge-diff/pulls

Also look in the main repo, search for "feature branch" in the name (e.g., Jenny has an API change out right now).

We have notes from our bi-weekly meeting here: https://docs.google.com/document/d/1j_UqnJRvB7AywfZauHybVVNCOoDDA1AGWGxzPGE08ko/edit# (join the wg-apply mailing list if you want to read)

We also have meeting recordings although we might be behind publishing them.

[AishSundar]

@lavalamp @apelisse what is the confidence level of this feature making it to Alpha in 1.13? Are these 3 PRs the only ones pending?

[spiffxp]

@lavalamp right my Q was more whether any of the feature branch stuff was going to land in master, otherwise it doesn't seem like this should be on our radar; the wg-apply notes are pretty spartan in that regard

There's the roadmap doc mentioned in April, but it's unclear to me whether that's still valid, and if so, which Phase we're currently in vs. aiming for

Based on your latest comment in the sig-api-machinery meeting notes I'm trying to ascertain what work items we should be watching for "not sure we'll make it to alpha in time" and whether "alpha" implies landing the feature branch to master

[lavalamp]

@spiffxp Yes, making it to alpha is the same thing as merging the feature branch back into master.

@AishSundar No, there are many PRs yet to be written. Look at the closed PRs in that repo for an estimate of the recent velocity. Additionally we will need more PRs to the feature branch in the main repo.

Can you two help me understand why this level of detail is necessary/useful? We still have 3ish weeks before anything freezes or slushes, no? If the branch doesn't get merged by then, we will have to push this off.

[AishSundar]

@lavalamp since this is a short release cycle the release team is trying to assess, early on, the amount of work pending for each planned feature and chances of any possible slips. This will help us track these better through the cycle

[apelisse]

There is definitely some work left to get this in 1.13 and chances that it slips are non-negligible. However, we still want to take our chance and hope that the few weeks left will be enough to get to alpha quality.

I'm happy to help you track that item in any way possible and can come back to you on a regular basis to give you a status. Hope that helps, thanks.

[AishSundar]

@apelisse for now if you can just point us to the list of open PRs and open issues (for unopened PRs) that will be great. we will touch base early November to see where we are. Thanks.

@kacole2 as FYI

[lavalamp]

We aren't tracking our work via specific issues that need specific PRs written, that would be fairly heavyweight for us. We are using this spreadsheet: https://docs.google.com/spreadsheets/d/1ZHTDyiQssYBzs7DQWQd70bNQybeyS0m-S1aIS_zo-78/edit?pli=1#gid=0

(you're probably already in some email group that has access)

[lavalamp]

In an offline chat with @spiffxp it seems you're actually trying to evaluate risk; I think the questions above don't actually make sense for this particular effort given that this is happening in a feature branch, which is probably why we're talking past each other.

• In terms of risk to stability, we won't be merging it if it's not meeting the bar before the window closes, so there's very little risk. All of our changes are in the feature branch or other repos so it's not like we'd leave master in a half broken state if we don't make it.
• In terms of risk of not getting to the finish line in time, we're well aware that time is short and there's a good chance we won't make the release.

[tfogo]

Hi @lavalamp and @apelisse, I'm the docs wrangler for the 1.13 release. Could you please open a placeholder PR for the docs for this enhancement against the dev-1.13 branch of k/website and send me a link? If you already have a docs PR open, or if this doesn't require docs in k/website, please let me know.

The deadline for placeholder PRs for the 1.13 release is November 8. So it's important to make a docs PR as soon as possible.

If you have any questions about any of this, I'm happy to help. You can also message me on slack (I'm tfogo there too).

Thanks!

[apelisse]

@tfogo Thanks for your help! I created it here: https://github.com/kubernetes/website/pull/10812

[guineveresaenger]

Hi @lavalamp and @apelisse - I'm Enhancements Shadow for 1.13. Reading through this thread and considering the method of tracking this feature, could you please update the release team with the likelihood of this enhancement making the 1.13 release?

Code slush begins on 11/9 and code freeze is 11/15.

Thank you!

[apelisse]

Hi @guineveresaenger, there are still chances that we miss the release, but we're doing everything we can to have a high-quality alpha feature in 1.13!

[AishSundar]

@apelisse can we please time-box the Go/NoGo decision to Wednesday (11/14) next week. At this point in the cycle we expect all 1.13 enhancements to have all code and test PRs either merged or very close to merging. I understand this feature is being developed in a feature branch. But with Code freeze next Friday (11/16), we need to merge it into master atleast by early Wednesday to get stable CI signals for a couple of days from Master. If that's not possible we will have to push it to 1.14. Thanks

@kacole2

[lavalamp]

We found a couple bugs at the last second so we will merge this as the first thing for 1.14 when master opens.

[AishSundar]

Thanks for the update @lavalamp.

@kacole2 @tfogo @marpaia @kbarnard10 as FYI

[claurence]

@apelisse @lavalamp Hello - I’m the enhancement’s lead for 1.14 and I’m checking in on this issue to see what work (if any) is being planned for the 1.14 release. Enhancements freeze is Jan 29th.

[apelisse]

Hello @claurence, we're planning to release this feature alpha this cycle! I just updated the description to reflect the new milestone. Anything else I need to update?

[claurence]

@apelisse sounds good! I'll add this to our 1.14 tracking sheet.

[felixfbecker]

What would the API request done by the client look like after this? I assume it would send the full local resource definition, but would it still be a PATCH request? Or a PUT?

I'm really excited about this, it takes out a lot of complexity from custom clients.

[apelisse]

Yes, it will receive the local object on the PATCH verb, with a specific content-type.

[felixfbecker]

Btw the link to the design proposal is broken

[apelisse]

Fixed, thanks, good catch.

[felixfbecker]

This seems to be the latest link https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/0006-apply.md

[felixfbecker]

Btw, all the design Google docs linked in there are not publicly viewable.

[apelisse]

Hi Felix, that doc needs a massive clean-up, I'll take care of that right after code-freeze (or before if we have extra-time). Thanks!

[lavalamp]

I am back, maybe I can update the KEP.

[liggitt]

/assign lavalamp

[cody-clark]

Hi @apelisse! I'm one of the v1.14 docs release shadows.

Does this enhancement require any new docs (or modifications)?

Just a friendly reminder we're looking for a PR against k/website (branch dev-1.14) due by Friday, March 1. It would be great if it's the start of the full documentation, but even a placeholder PR is acceptable. Let me know if you have any questions!

[apelisse]

Thanks for the reminder @cody-clark, we definitely need documentation!

[cody-clark]

Perfect! I'll mark it in the tracking sheet. Thanks for the quick reply, @apelisse!