Conversation
|
🚀 preview deployed successfully to Fermyon Cloud and available at https://spin-docs-pr-169-ggwum9wb.fermyon.app |
itowlson
left a comment
itowlson
left a comment
There was a problem hiding this comment.
I left a lot of comments but I am not sure how actionable they are, or if they are too structural to be readily acted on in the time we have. Anyway here they are for your consideration or rejection but I don't think any of them are blocking if it comes down to it.
content/blog/announcing-spin-3-6.md
Outdated
|
|
||
| Earlier this week, the CNCF Spin project released [Spin v3.6.0](https://github.com/spinframework/spin/releases/tag/v3.6.0) which includes support for a new release candidate of the upcoming WASIp3 release, WASIp3 component instance reuse, and experimental support for the [WASI OTel](https://github.com/webAssembly/wasi-otel) proposal! | ||
|
|
||
| ## WASIp3 Component Instance Reuse |
There was a problem hiding this comment.
I would maybe bucket this under "what's new in WASI Preview 3" or something, which could cover "there's a new RC with... what" and "instances now get reused". At the moment the opening para teases P3 goodies but all we get is instance reuse!
content/blog/announcing-spin-3-6.md
Outdated
|
|
||
| Earlier this week, the CNCF Spin project released [Spin v3.6.0](https://github.com/spinframework/spin/releases/tag/v3.6.0) which includes support for a new release candidate of the upcoming WASIp3 release, WASIp3 component instance reuse, and experimental support for the [WASI OTel](https://github.com/webAssembly/wasi-otel) proposal! | ||
|
|
||
| ## WASIp3 Component Instance Reuse |
There was a problem hiding this comment.
For me, this section felt rather long for what is kind of a behind-the-scenes feature. I get that it's important but it's a lot of detail for a release announcement and I worry that readers will skip past the detail and miss the crucial bits. It would be great as a post in itself, but for the announcement I'd suggest condensing it to maybe 3-4 (?) paragraphs? Or however long it takes to provide the key context and messages of course.
Or rework it to be more action-oriented. Show some code. People love code. (Although not too much code. Or I'll start moaning about walls of text. I'm a regular Scylla and Charybdis.) E.g. showing "this works in P2 but in P3 you have to change it like this." Dunno if that would work but it's a possible way to make this a "show" rather than lengthy exposition.
content/blog/announcing-spin-3-6.md
Outdated
|
|
||
| In practice, this translates to higher throughput and lower memory usage, since fewer component instances are required to sustain a given request volume. This behavior is intentionally limited to WASIp3: Spin does not reuse WASIp2 instances by default, as those components were not necessarily written with reentrancy or concurrent execution in mind. | ||
|
|
||
| Spin 3.6 ships with conservative defaults for tweaking the behavior of instance reuse: |
There was a problem hiding this comment.
This and the next few paragraphs could be dropped I think?
content/blog/announcing-spin-3-6.md
Outdated
|
|
||
| All reuse parameters can be tune, or disabled entirely, via `spin up` command-line options. Each option also supports specifying a range of values, in which case Spin will pseudo-randomly select parameters at runtime. This makes it straightforward to stress-test components under varying concurrency and lifecycle conditions without rebuilding or redeploying. | ||
|
|
||
| Instance reuse is enabled by default for WASIp3 components, but remains experimental while WASIp3 continues toward formal stabilization. We expect these semantics to solidify alongside the WASI standard itself. |
There was a problem hiding this comment.
This perhaps needs to be more prominent. You don't have to worry about this unless you're already on Experimental Voyage P3.
| // Propagate the trace context from the Spin host so your | ||
| // spans appear as children of the Spin-level request span | ||
| let wasi_propagator = opentelemetry_wasi::TraceContextPropagator::new(); | ||
| let _guard = wasi_propagator.extract(&Context::current()).attach(); |
There was a problem hiding this comment.
egad this is ceremonious
but I suppose it is what it is for now
One thing I'd strongly consider, given the length of even this minimal code snippet, is breaking this up a la
We'll start out by importing some types we're going to need later
WALL OF TEXT 1
Now let's set up the OTel context
WALL OF TEXT 2
With all that done, we can finally trace the living crap out of some code
WALL OF TEXT 3
You can find the full sample at LINKY LINK LINK
There was a problem hiding this comment.
@calebschoepp the ceremony here is basically always needed, and one wouldn't really deviate from it, right? If that's the case, would it make sense to add a single function to your crate that does all this and returns a struct encapsulating the various bits here?
It seems like that should be a pretty quick win, so maybe we can even get it out before publishing this post?
There was a problem hiding this comment.
That seems appropriate to do when we wrap this up in the Spin SDK. I'm less sure that doing that would be idiomatic in a OTel SDK. Anyways, seems like the blog post has already landed.
content/blog/announcing-spin-3-6.md
Outdated
|
|
||
| The key pieces are: | ||
|
|
||
| - **`WasiSpanProcessor`** — a `SpanProcessor` that forwards span start/end events to the host via WASI OTel WIT calls instead of exporting them over the network from the guest. |
There was a problem hiding this comment.
If you break up the code, these can go closer to their context - perhaps even motivate the code. Right now they're kind of breaking the flow of "here is the app" and "here's how to run it."
content/blog/announcing-spin-3-6.md
Outdated
|
|
||
| This is really exciting because observability is a big pain point in the WebAssembly ecosystem and WASI OTel is a step towards solving the problem. It unlocks first-class observability for Spin appications that tightly integrates with the host observability. | ||
|
|
||
| > Because this is still an in-progress proposal, the underlying WIT interfaces may change in future releases. That said, we think it's ready enough to start building with today. |
There was a problem hiding this comment.
I'm not sure how helpful it is to talk WIT interfaces when the way it's surfaced is so seamless - the developer is almost unaware that there are any WIT interfaces involved, no bindgen or cruft like that. I wonder if we can rephrase this somehow? (But no worries if not.)
Signed-off-by: Brian Hardock <brian.hardock@fermyon.com>
fibonacci1729
force-pushed
the
spin-3.6
branch
from
8fb0bd3 to
1306153
Compare
Signed-off-by: itowlson <ivan.towlson@fermyon.com>
4 participants
No description provided.