removing the deltafifo to simplify the informer code

[shawkins]

Description

The deltafifo adds a lot of complexity to the informer implementation with little to no benefit - it could only combine some delete events. It would be more straight-forward to just act directly over the cache. This reduces the number of threads dedicated to an informer by 1.

It's not in these changes, but it will allow the cache interface to become fully type safe

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• Code contributed by me aligns with current project license: Apache 2.0
• I Added CHANGELOG entry regarding this change
• I have implemented unit tests to cover my changes
• I have added/updated the javadocs and other documentation accordingly
• No new bugs, code smells, etc. in SonarCloud report
• I tested my code in Kubernetes
• I tested my code in OpenShift

[centos-ci]

Can one of the admins verify this patch?

[shawkins]

I don't agree with the sonarcloud bugs - seems like a valid usage of capturing arguments.

I can clear out the type related code smells on a follow-on pr to refine the Cache interface.

[shawkins]

I'll rebase this after #3055 is committed

[rohanKanojia]

I like this change. I think it'll simplify the flow a lot. Please note that with this we're diverging from client-go's notification distribution mechanism where it pops item from DeltaFifo and processes it.

https://github.com/kubernetes/client-go/blob/master/tools/cache/controller.go#L181

[manusa]

I think that many of the low-level implementations that were initially ported from the Go Shared Informers made sense from a Golang perspective but not in a Java word.
I haven't had the chance to review this in depth, but as long as the user/consumer's behavior is more or less compliant with that of Client Go, it should be OK.

[shawkins]

I haven't had the chance to review this in depth, but as long as the user/consumer's behavior is more or less compliant with that of Client Go, it should be OK.

From a consumer's perspective nothing meaningful changes. The deltafifo is acting as an intermediary between the watch events and the cache updates / event distribution. However the cost of updating the deltafifo should if roughly the same as an operation directly on the cache (similar global lock, several hash lookups, etc.) - and the end event distribution is already happening on a different thread with the SharedProcessor. The deletefifo is not combining events in any meaningful way. It's only a narrow check for duplicate deletion, which should be handled anyway by the removal of the object from cache by the first delete. So I can't see much value in it currently and it holds a thread.

[manusa]

Hi @shawkins
I think you might haven't noticed, but this PR has now conflicts.

[shawkins]

I think you might haven't noticed, but this PR has now conflicts.

I can update it if you want. My understanding was this may not go in anytime soon, so I'm not sure how often I need to rebase it.

[manusa]

Relates to: #2010

[manusa]

My understanding was this may not go in anytime soon, so I'm not sure how often I need to rebase it.

OK sorry, I must be missing something. Why shouldn't this be merged?

[shawkins]

That was from a side conversation with @metacosm about not holding up the 5.4 release. I'll go ahead an update it.

[manusa]

That was from a side conversation with @metacosm about not holding up the 5.4 release. I'll go ahead an update it.

I think I just read this in the Java Operators GChat.

The idea is to release 5.4 with not too much delay. I wanted to include most of the Informer improvements, and the required generator fixes. Since the latter need an updated version of Sundr.io I think we might be looking into next week for the 5.4 release.

[rohanKanojia]

test failure doesn't seem related to this PR:

Error:  io.fabric8.crd.generator.CRDGeneratorTest.checkCRDGenerator  Time elapsed: 0.025 s  <<< FAILURE!
org.opentest4j.AssertionFailedError: expected: not <null>
	at io.fabric8.crd.generator.CRDGeneratorTest.lambda$checkCRDGenerator$5(CRDGeneratorTest.java:224)
	at io.fabric8.crd.generator.CRDGeneratorTest.outputCRDIfFailed(CRDGeneratorTest.java:146)
	at io.fabric8.crd.generator.CRDGeneratorTest.checkCRDGenerator(CRDGeneratorTest.java:219)

[INFO] Running io.fabric8.crd.generator.utils.TypesTest
[INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 s - in io.fabric8.crd.generator.utils.TypesTest
[INFO] Running io.fabric8.crd.generator.v1.JsonSchemaTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 s - in io.fabric8.crd.generator.v1.JsonSchemaTest
[INFO] 
[INFO] Results:
[INFO] 
Error:  Failures: 
Error:    CRDGeneratorTest.checkCRDGenerator:219->outputCRDIfFailed:146->lambda$checkCRDGenerator$5:224 expected: not <null>
[INFO] 
Error:  Tests run: 20, Failures: 1, Errors: 0, Skipped: 0
[INFO] 
[INFO] ------------------------------------------------------------------------

Anyway, I've restarted workflow

[metacosm]

This specific issue should go away with the sundrio update (hopefully).

[manusa]

LGTM, thx!

[shawkins]

I have one more change I'd like to make here - I'd like to make the replace logic more consistent.

[manusa]

I have one more change I'd like to make here - I'd like to make the replace logic more consistent.

I guess we're still waiting for the sundr.io fix, so feel free ;)

[shawkins]

Okay this change fully makes use of the underlying stores replace method, and then processes notifications.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
14 Code Smells

82.8% Coverage
0.0% Duplication