-
Notifications
You must be signed in to change notification settings - Fork 251
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
Implement wasi-keyvalue #2486
Implement wasi-keyvalue #2486
Conversation
I had to add the |
Do folks have any insights on how to move this forward? It seems to work but I am not quite sure what do about the worlds stuff:
|
Yup, I can take a look tomorrow morning. |
@kate-goldenring might also be interested, given her recent work on the specification. |
crates/key-value/src/lib.rs
Outdated
async fn open( | ||
&mut self, | ||
identifier: String, | ||
) -> anyhow::Result<Result<Resource<wasi_keyvalue::store::Bucket>, wasi_keyvalue::store::Error>> |
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.
You can use the trappable_error_type
option to make the signatures here a bit easier to work with. See the llm
implementation for an example use.
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.
Thanks @rylev. I gave this a try and am not sure how I feel about. I've left it in a separate commit and would value your thoughts...
crates/key-value/src/lib.rs
Outdated
) -> anyhow::Result<Result<wasi_keyvalue::store::KeyResponse, wasi_keyvalue::store::Error>> | ||
{ | ||
if cursor.unwrap_or_default() != 0 { | ||
anyhow::bail!("list_keys: cursor not supported"); |
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.
Is the plan to eventually support the cursor?
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.
"Plan" is a strong word but, yes, it would be desirable to do on back-ends that support it. For this initial implementation I stuck to using the existing KV implementation which unfortunately do not support cursors.
wit/world.wit
Outdated
@@ -16,6 +16,7 @@ world http-trigger-rc20231018 { | |||
world platform { | |||
include wasi:cli/[email protected]; | |||
import wasi:http/[email protected]; | |||
import wasi:keyvalue/[email protected]; |
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 definitely need to decide how we want to handle introducing new imports. This will break any Spin runtime that does not have wasi:keyvalue
support.
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.
It seems like we should be bumping the WIT package version here right? This is still a little scary as we haven't even done it with WASI 0.2.1 yet...
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.
Yes, this was one of my questions: #2486 (comment). Do we need a separate conversation about how to do this?
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.
Do we need a separate conversation about how to do this?
Probably? I'm not sure that anyone knows how best to handle this yet.
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.
LGTM overall -- thanks for doing this!
I expect we'll need to implement cursors before we can really claim to support wasi:keyvalue/store
, and that may be the most interesting part of this project given the variety of backends we now support (SQLite, Redis, and Azure).
wit/world.wit
Outdated
@@ -30,6 +31,7 @@ world platform { | |||
world platform-rc20231018 { | |||
include wasi:cli/[email protected]; | |||
import wasi:http/[email protected]; | |||
import wasi:keyvalue/[email protected]; |
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.
I'd recommend not adding anything new to platform-rc20231018
-- it's only really here for backwards compatibility. In hindsight, I think we probably shouldn't have added mqtt
either.
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.
I agree! The trouble is that the tests all (currently) use this world, so if we want tests for wasi-keyvalue
then we will need to rev the test world, and I'm not sure of the implications of that. #2486 (comment)
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.
LGTM. @itowlson should we mark this as ready to review?
@kate-goldenring I was planning to leave it as draft until we have a decision on WIT versioning. I can mark ready for review and label "do not merge" if that would be better? |
@itowlson leaving as is is fine. Thanks for clarifying the decision criteria. |
Just to validate an assumption I had reading this PR: this PR adds support for the WASI KV proposal — specifically, it allows guests to use the proposal to interact with stores — and stores are still managed through the manifest Thanks! |
@radu-matei Yes. The KV stores are the exact same KV stores as you would get if you used the Spin APIs, specified and configured in exactly the same way. |
Is the intention to update this PR and have WASI KV be part of the Spin world? I am not sure what the decision criteria for WIT versioning (which I understand is blocking this PR) is. |
@radu-matei That is the intention, but we don't yet know how to version the Spin world (at least I don't, and from previous comments this seems to be a general problem, unless the community has figured something out since June). |
5d8d92c
to
94a8ca4
Compare
94a8ca4
to
cc5eac0
Compare
514500a
to
14b0cc1
Compare
Signed-off-by: itowlson <[email protected]>
14b0cc1
to
6d594b9
Compare
An exploratory PR for exploring, apropos of #2447.