-
Notifications
You must be signed in to change notification settings - Fork 42
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
[MIG-699] Add wrapper around cached client that waits for cache to catch up before returning from Create
, Update
#1035
Comments
Create
, Update
, Delete
.
I put together a proof of concept for this and it's working really well so far. I've been able to observe the cache taking anywhere from 10ms - 500ms to catch up after an update is posted, but because I modified the client to block we never run into race conditions where something we expected is missing. When I first added the cache (before I implemented sync blocking) I observed migration failure every time with DVM expecting resources (e.g. secrets) it had just created to exist. This problem went away immediately after getting cache-sync blocking I think providing the ability for the developer to decide if an API call should block on success or not will be important. PV discovery with cache (354 ms)PV discovery without cache (10.01 seconds)New phase timing |
Remaining potential problems:
|
Create
, Update
, Delete
.Create
, Update
Create
, Update
Create
, Update
This cache sync approach is block-on-write. I wrote about a block-on-read approach in #1034, but I don't think that will work with deletions
See #1034 for problem statement.
Describe the solution you'd like
Add a wrapper around cached client. When
Create
orUpdate
is called, wait until the cache catches up by performingGet
calls against the cache to verify that the new resourceVersion is retrievable from the cache.Have some sane timeout like 3 seconds on this block in case a resource that was modified by us was immediately deleted and will never show up in the cache.
Also, we could provide a parameter on client calls so that the user can decide whether to block on cache sync. This would be useful if we know we won't be looking for a resource later on, but would potentially be unsafe.
The text was updated successfully, but these errors were encountered: