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

Make sure no op updates don't affect the resource version due to serverside apply #81673

Merged
merged 1 commit into from
Aug 23, 2019

Conversation

jennybuckley
Copy link

What type of PR is this?
/kind bug
/priority important-soon
/sig api-machinery
/wg apply
/cc @apelisse

What this PR does / why we need it:
Adds a test to make sure no op updates don't affect the resource version due to serverside apply, and fixes a bug where this wasn't true

Does this PR introduce a user-facing change?:

NONE

@k8s-ci-robot k8s-ci-robot added release-note-none Denotes a PR that doesn't merit a release note. kind/bug Categorizes issue or PR as related to a bug. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. 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. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. wg/apply area/apiserver area/test sig/testing Categorizes an issue or PR as relevant to SIG Testing. labels Aug 20, 2019
// Update the time in the managedFieldsEntry for this operation
managed.Times[manager] = &metav1.Time{Time: time.Now().UTC()}
// Update the time in the managedFieldsEntry for this operation if the fieldset changed
if originalManagedFields == nil || !managed.Fields[manager].Set().Difference(originalManagedFields.Set()).Empty() {
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would mean that we only update the time on these entries when the field set changes, not when the values change of something which is already owned.

Also, we don't need to check the reverse difference because an updater's fieldset can only grow by doing an update operation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

an updater's fieldset can only grow by doing an update operation.

Can you elaborate on that? What if you remove an optional field?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing a field or list item is something I didn't think of. We can check both directions of the difference then. But I wasn't sure if this is even the direction we want to go for when to update the time

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about it more, we could probably do this instead:
if c, err := liveObjTyped.Compare(newObjTyped); err == nil && !c.IsSame() {

@jennybuckley
Copy link
Author

/retest

@apelisse
Copy link
Member

That's very important, thanks for doing it

"metadata": {
"name": "` + podName + `"
},
"spec": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to have a more sophisticated object so that we know that maps, associative list and everything keep things in order?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can do that, but as it is, the ownership already looks like:

"fields": {
	"f:spec": {
		"f:containers": {
			"k:{\"name\":\"test-container\"}": {
				"f:image": {},
				"f:imagePullPolicy": {},
				"f:name": {},
				"f:resources": {},
				"f:terminationMessagePath": {},
				"f:terminationMessagePolicy": {},
				".": {}
			}
		},
		"f:dnsPolicy": {},
		"f:enableServiceLinks": {},
		"f:restartPolicy": {},
		"f:schedulerName": {},
		"f:securityContext": {},
		"f:terminationGracePeriodSeconds": {}
	}
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, multiple containers does help

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

multiple containers and a few labels should cover most of the interesting features

@k8s-ci-robot k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Aug 20, 2019
Copy link
Member

@apelisse apelisse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, I would like to see if the comparison is expensive

// Update the time in the managedFieldsEntry for this operation
managed.Times[manager] = &metav1.Time{Time: time.Now().UTC()}
// Update the time in the managedFieldsEntry for this operation if the object changed
if same, err := f.isSame(liveObjTyped, newObjTyped); err == nil && !same {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should run before/after benchmarks to see if that's fine

"metadata": {
"name": "` + podName + `"
},
"spec": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, multiple containers does help

@jennybuckley
Copy link
Author

@apelisse

jennybuckley@jennybuckley:~/Projects/k8s-p3/src/k8s.io/kubernetes$ benchcmp ~/old.bench ~/new.bench
benchmark                       old ns/op     new ns/op     delta
BenchmarkApplyNewObject-12      1613996       1517044       -6.01%
BenchmarkUpdateNewObject-12     1794913       2118134       +18.01%
BenchmarkRepeatedUpdate-12      636785        691073        +8.53%
BenchmarkSetToFields-12         5298          5212          -1.62%
BenchmarkFieldsToSet-12         10932         10716         -1.98%
BenchmarkYAMLToTyped-12         56229         57950         +3.06%

benchmark                       old allocs     new allocs     delta
BenchmarkApplyNewObject-12      6826           6826           +0.00%
BenchmarkUpdateNewObject-12     7893           10436          +32.22%
BenchmarkRepeatedUpdate-12      2246           2665           +18.66%
BenchmarkSetToFields-12         14             14             +0.00%
BenchmarkFieldsToSet-12         82             82             +0.00%
BenchmarkYAMLToTyped-12         152            152            +0.00%

benchmark                       old bytes     new bytes     delta
BenchmarkApplyNewObject-12      482317        482338        +0.00%
BenchmarkUpdateNewObject-12     534374        704804        +31.89%
BenchmarkRepeatedUpdate-12      189837        222702        +17.31%
BenchmarkSetToFields-12         1016          1016          +0.00%
BenchmarkFieldsToSet-12         6419          6419          +0.00%
BenchmarkYAMLToTyped-12         27405         27413         +0.03%

@jennybuckley
Copy link
Author

I'm guessing mostly because compare is still allocating a merged object which we throw away

@apelisse
Copy link
Member

Yeah, that's what I was expecting too ...

@jennybuckley
Copy link
Author

And the other benchmarks:

$ benchcmp ~/old.bench ~/new.bench
benchmark                                                    old ns/op     new ns/op     delta
BenchmarkNoServerSideApply/List1-12                          1181222       1176036       -0.44%
BenchmarkNoServerSideApply/List20-12                         2284292       2251594       -1.43%
BenchmarkNoServerSideApply/List200-12                        12482119      12458413      -0.19%
BenchmarkNoServerSideApply/List2000-12                       80365197      80411328      +0.06%
BenchmarkNoServerSideApply/RepeatedUpdates-12                3398614       2946557       -13.30%
BenchmarkNoServerSideApply/Post1-12                          4098853       4022709       -1.86%
BenchmarkNoServerSideApply/Post10-12                         8309809       8184137       -1.51%
BenchmarkNoServerSideApply/Post50-12                         23449642      24398193      +4.05%
BenchmarkNoServerSideApplyButSameSize/List1-12               1242427       1208009       -2.77%
BenchmarkNoServerSideApplyButSameSize/List20-12              2854599       2799189       -1.94%
BenchmarkNoServerSideApplyButSameSize/List200-12             20112737      19981010      -0.65%
BenchmarkNoServerSideApplyButSameSize/List2000-12            132777713     152350769     +14.74%
BenchmarkNoServerSideApplyButSameSize/RepeatedUpdates-12     4203279       4203382       +0.00%
BenchmarkNoServerSideApplyButSameSize/Post1-12               4934311       5024805       +1.83%
BenchmarkNoServerSideApplyButSameSize/Post10-12              9418578       9921928       +5.34%
BenchmarkNoServerSideApplyButSameSize/Post50-12              27826752      27878165      +0.18%
BenchmarkServerSideApply/List1-12                            1340855       1413259       +5.40%
BenchmarkServerSideApply/List20-12                           4851633       4955054       +2.13%
BenchmarkServerSideApply/List200-12                          34224169      34746427      +1.53%
BenchmarkServerSideApply/List2000-12                         224618376     246000197     +9.52%
BenchmarkServerSideApply/RepeatedUpdates-12                  5522425       6037619       +9.33%
BenchmarkServerSideApply/Post1-12                            6540882       7112155       +8.73%
BenchmarkServerSideApply/Post10-12                           11559305      11591143      +0.28%
BenchmarkServerSideApply/Post50-12                           39453454      41130685      +4.25%

benchmark                                                    old allocs     new allocs     delta
BenchmarkNoServerSideApply/List1-12                          593            593            +0.00%
BenchmarkNoServerSideApply/List20-12                         4720           4720           +0.00%
BenchmarkNoServerSideApply/List200-12                        43679          43677          -0.00%
BenchmarkNoServerSideApply/List2000-12                       432775         432770         -0.00%
BenchmarkNoServerSideApply/RepeatedUpdates-12                1907           1907           +0.00%
BenchmarkNoServerSideApply/Post1-12                          5445           5445           +0.00%
BenchmarkNoServerSideApply/Post10-12                         54862          54860          -0.00%
BenchmarkNoServerSideApply/Post50-12                         274599         274480         -0.04%
BenchmarkNoServerSideApplyButSameSize/List1-12               608            608            +0.00%
BenchmarkNoServerSideApplyButSameSize/List20-12              4925           4926           +0.02%
BenchmarkNoServerSideApplyButSameSize/List200-12             45731          45734          +0.01%
BenchmarkNoServerSideApplyButSameSize/List2000-12            453372         453395         +0.01%
BenchmarkNoServerSideApplyButSameSize/RepeatedUpdates-12     1964           1968           +0.20%
BenchmarkNoServerSideApplyButSameSize/Post1-12               5572           5571           -0.02%
BenchmarkNoServerSideApplyButSameSize/Post10-12              56136          56132          -0.01%
BenchmarkNoServerSideApplyButSameSize/Post50-12              280779         280767         -0.00%
BenchmarkServerSideApply/List1-12                            630            630            +0.00%
BenchmarkServerSideApply/List20-12                           5367           5366           -0.02%
BenchmarkServerSideApply/List200-12                          50159          50164          +0.01%
BenchmarkServerSideApply/List2000-12                         497353         497459         +0.02%
BenchmarkServerSideApply/RepeatedUpdates-12                  8258           9496           +14.99%
BenchmarkServerSideApply/Post1-12                            10922          12268          +12.32%
BenchmarkServerSideApply/Post10-12                           109567         122975         +12.24%
BenchmarkServerSideApply/Post50-12                           548079         615141         +12.24%

benchmark                                                    old bytes     new bytes     delta
BenchmarkNoServerSideApply/List1-12                          52494         52428         -0.13%
BenchmarkNoServerSideApply/List20-12                         559171        559138        -0.01%
BenchmarkNoServerSideApply/List200-12                        5491381       5440290       -0.93%
BenchmarkNoServerSideApply/List2000-12                       51660430      51660935      +0.00%
BenchmarkNoServerSideApply/RepeatedUpdates-12                153417        153462        +0.03%
BenchmarkNoServerSideApply/Post1-12                          588174        587805        -0.06%
BenchmarkNoServerSideApply/Post10-12                         5995108       5995144       +0.00%
BenchmarkNoServerSideApply/Post50-12                         30036257      30004028      -0.11%
BenchmarkNoServerSideApplyButSameSize/List1-12               75205         75151         -0.07%
BenchmarkNoServerSideApplyButSameSize/List20-12              996043        995795        -0.02%
BenchmarkNoServerSideApplyButSameSize/List200-12             10615280      10640515      +0.24%
BenchmarkNoServerSideApplyButSameSize/List2000-12            101045079     101049658     +0.00%
BenchmarkNoServerSideApplyButSameSize/RepeatedUpdates-12     217272        218164        +0.41%
BenchmarkNoServerSideApplyButSameSize/Post1-12               680315        679998        -0.05%
BenchmarkNoServerSideApplyButSameSize/Post10-12              6901938       6900597       -0.02%
BenchmarkNoServerSideApplyButSameSize/Post50-12              34526224      34503709      -0.07%
BenchmarkServerSideApply/List1-12                            79463         79408         -0.07%
BenchmarkServerSideApply/List20-12                           1091447       1091469       +0.00%
BenchmarkServerSideApply/List200-12                          11554903      11658318      +0.89%
BenchmarkServerSideApply/List2000-12                         110666228     110665348     -0.00%
BenchmarkServerSideApply/RepeatedUpdates-12                  769688        871287        +13.20%
BenchmarkServerSideApply/Post1-12                            1117885       1234671       +10.45%
BenchmarkServerSideApply/Post10-12                           11278539      12415726      +10.08%
BenchmarkServerSideApply/Post50-12                           56475775      62137058      +10.02%

@jennybuckley
Copy link
Author

Okay, without the comparison, the new benchcmp is much better:

$ benchcmp ~/old.bench ~/new.bench
benchmark                       old ns/op     new ns/op     delta
BenchmarkApplyNewObject-12      1625103       1569003       -3.45%
BenchmarkUpdateNewObject-12     1779586       1685061       -5.31%
BenchmarkRepeatedUpdate-12      628458        606244        -3.53%
BenchmarkSetToFields-12         5094          5156          +1.22%
BenchmarkFieldsToSet-12         10543         10078         -4.41%
BenchmarkYAMLToTyped-12         55939         55581         -0.64%

benchmark                       old allocs     new allocs     delta
BenchmarkApplyNewObject-12      6826           6826           +0.00%
BenchmarkUpdateNewObject-12     7893           7936           +0.54%
BenchmarkRepeatedUpdate-12      2246           2249           +0.13%
BenchmarkSetToFields-12         14             14             +0.00%
BenchmarkFieldsToSet-12         82             82             +0.00%
BenchmarkYAMLToTyped-12         152            152            +0.00%

benchmark                       old bytes     new bytes     delta
BenchmarkApplyNewObject-12      482346        482326        -0.00%
BenchmarkUpdateNewObject-12     534381        536068        +0.32%
BenchmarkRepeatedUpdate-12      189852        189906        +0.03%
BenchmarkSetToFields-12         1016          1016          +0.00%
BenchmarkFieldsToSet-12         6419          6419          +0.00%
BenchmarkYAMLToTyped-12         27409         27415         +0.02%

@jennybuckley jennybuckley force-pushed the grouping-etcd branch 2 times, most recently from 8e5b6e6 to 46bddb7 Compare August 20, 2019 21:22
Copy link
Member

@apelisse apelisse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If i don't look at the failing . tests, it looks good :-)

// operations from the same manager if the object changed
if f, ok := managed.Fields["self"]; ok {
if old, ok := managed.Fields[manager]; ok {
f = fieldpath.NewVersionedSet(f.Set().Union(old.Set()), f.APIVersion(), f.Applied())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting how we could remove that union from smd now

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah we could do that and simplify things, just need to make sure that people don't give the same manager name to smd as any existing manager for updates (maybe return an error?)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine. As long as we never send the same manager, the union is always going to be a no-op?

@jennybuckley
Copy link
Author

@apelisse the tests are passing now

@apelisse
Copy link
Member

/lgtm
/approve

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 21, 2019
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: apelisse, jennybuckley

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 21, 2019
@k8s-ci-robot k8s-ci-robot merged commit 9ac0c59 into kubernetes:master Aug 23, 2019
@k8s-ci-robot k8s-ci-robot added this to the v1.16 milestone Aug 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/apiserver area/test cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/bug Categorizes issue or PR as related to a bug. lgtm "Looks good to me", indicates that a PR is ready to be merged. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. release-note-none Denotes a PR that doesn't merit a release note. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/testing Categorizes an issue or PR as relevant to SIG Testing. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants