-
Notifications
You must be signed in to change notification settings - Fork 49
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
Converting lattice cache to use a durable key value store #513
Conversation
Signed-off-by: Kevin Hoffman <autodidaddict@users.noreply.github.com>
How are consumers expected to migrate from legacy to WCMDCACHE (which my brain is reading as jibberish). What does WCMD standfor? It seems possible to perform the migration in-place, i.e. instead of only reading into memory, call kv_put to the new bucket. |
Wcmd is wasmCloud metadata. I may have gone too far in trying to ensure someone else won't already have a bucket with that name. I can simplify. |
Thanks for pointing this out @ricochet , as written the code just caches in memory the old stream but never migrates to the new one. |
Converting to a draft until I can make the appropriate changes |
Signed-off-by: Kevin Hoffman <autodidaddict@users.noreply.github.com>
Signed-off-by: Kevin Hoffman <autodidaddict@users.noreply.github.com>
Signed-off-by: Kevin Hoffman <autodidaddict@users.noreply.github.com>
New version of the code will, for each lattice prefix, locate a previously created latticecache_xxx stream, read its entire contents, put each element in the new KV bucket, and then delete the old latticecache_xxx stream. |
Signed-off-by: Kevin Hoffman <autodidaddict@users.noreply.github.com>
Signed-off-by: Kevin Hoffman <autodidaddict@users.noreply.github.com>
Signed-off-by: Kevin Hoffman <autodidaddict@users.noreply.github.com>
Signed-off-by: Kevin Hoffman <autodidaddict@users.noreply.github.com>
Signed-off-by: Kevin Hoffman <autodidaddict@users.noreply.github.com>
Signed-off-by: Kevin Hoffman <autodidaddict@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My questions are addressed, but someone with deeper knowledge of the current caching mechanisms should give a more thorough review
…wards compatible) Signed-off-by: Kevin Hoffman <autodidaddict@users.noreply.github.com>
def cache_claims(lattice_prefix, key, claims) do | ||
:ets.insert(claims_table_atom(lattice_prefix), {key, claims}) | ||
end | ||
|
||
def uncache_claims(lattice_prefix, key) do | ||
:ets.delete(claims_table_atom(lattice_prefix), key) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We might want to consider a SafeEts
module like we have SafeGnat request/pub functionality. I know that :ets
operations will crash a genserver if the identifier doesn't refer to an existing table
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these tables are all guaranteed to be created before this stuff ever gets called. If the tables weren't created it means a mandatory supervisor never started, so we have bigger problems. however, I could add an implicit create in the call to something like claims_table_atom
🤔
Signed-off-by: Kevin Hoffman <autodidaddict@users.noreply.github.com>
Signed-off-by: Kevin Hoffman <autodidaddict@users.noreply.github.com>
Signed-off-by: Kevin Hoffman <autodidaddict@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
3/4 d'oh's later and it's great!
TL;DR @autodidaddict and I got on a call together and ran through some scenarios migrating from old (0.59.0 / pre-OTP refactor) scenarios and caught a few edge cases. Now the migration from older host configs and latticecache streams will be painless and older tools (like the older wash ctl clients) will work with linkdefs just fine.
This adds the use of a durable key value store for metadata storage in place of the old
LATTICECACHE_{prefix}
stream.This also deprecates the use of the
linkdefs.put
andlinkdefs.del
control interface operations, instead requiring clients to write directly to the key value bucket.Upon startup, if a pre-existing (legacy) lattice cache is discovered, that will be read into memory, a deprecation warning will be emitted.
This version of the host does not write to the deprecated lattice cache, and all change discovery from the cache occurs through ephemeral consumers against the new
WCMDCACHE_{prefix}
key/value bucket.