Skip to content
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

🎁 Pretty print cloud events via wasm #24

Closed

Conversation

cardil
Copy link
Member

@cardil cardil commented Apr 17, 2023

Conflicts fixed:

 - quarkus/src/main/java/com/redhat/openshift/knative/showcase/events/Endpoint.java
@openshift-ci
Copy link

openshift-ci bot commented Apr 17, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cardil

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@cardil cardil added kind/enhancement New feature or request and removed approved labels Apr 17, 2023
@cardil cardil marked this pull request as ready for review April 19, 2023 23:08
@openshift-ci openshift-ci bot requested review from aliok and lberk April 19, 2023 23:08
Copy link

@mgencur mgencur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cardil Hey, I have just put a few comments to get some clarification.

I'm not familiar with WASM but I suppose the code that actually does the formatting of the received cloud events is not in this PR. It's somewhere external? Looks like this PR loads and calls the WASM modele that was created somewhere else.

* @callback Log
* @param {string} message
* @param {...any} args
*/
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this belong to any function? If not, let's remove it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is used on line 69. This is done, so you get a code assist in IDE, like vscode.

const tmpDir = os.tmpdir()
const tmp = await fs.mkdtemp(`${tmpDir}/wasm-oci-`)
const reg = new WasmRegistry(tmp)
const image = Image.parse('quay.io/cardil/cloudevents-pretty-print@sha256:134269c7090bcb923d8b8764920bb25923e38411413eac7e4240524f1a40dc74')
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand it correctly, you created the cloudevents-pretty-print.wasm in advance, then put it in the image above and the application is now pulling the image and consuming the wasm file from it?
Where/how was the cloudevents-pretty-print.wasm created? Where's the code?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't put the whole WASM project in this repo, so not to cloud the project even more. I could transfer it to https://github.com/openshift-knative org, if you think it's a good idea.

However, I doubt the code in https://github.com/cardil/cloudevents-pretty-print will change in any significant way, so I don't know is that worth it.

@@ -105,6 +110,16 @@
<artifactId>frontend</artifactId>
<version>main</version>
</dependency>
<dependency>
<groupId>com.redhat.openshift.knative.showcase</groupId>
<artifactId>cloudevents-pp-wasm</artifactId>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where's the source code for this dependency?

Copy link
Member Author

@cardil cardil Apr 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code is here: https://github.com/cardil/cloudevents-pretty-print (in Rust). It gets built onto a WASM module, and published on quay.io/cardil/cloudevents-pretty-print

The script in frontend app, downloads that WASM module from the registry, and packages it as jar onto local ~/.m2 directory.

That's done, so it is easily available for Java app (same as web files were provided before)

@cardil
Copy link
Member Author

cardil commented Apr 20, 2023

Here's a quick performance check of WASM pretty printer in Quarkus:

wasm-pp-quarkus-perf

@cardil cardil requested a review from mgencur April 21, 2023 08:57
@mgencur
Copy link

mgencur commented Apr 21, 2023

Hi @cardil , it's good to see WASM in action and how it can be glued together. Thanks for that. The code looks good but it also brings huge complexity to this showcase application that doesn't pay off.

If I exclude the package-lock.json from my consideration it's still about 400 lines of glue code just to load and use the WASM module. This source code of this WASM module is also in a different repository, written in a different language and also pulled through an image that was published to your own image registry (the personal registry is a minor details, the complexity of pulling this through image will remain when moving under openshift-knative/showcase). The actual code that does the formatting of the cloud event is just about 40-50 lines in RUST and as you said it's not likely that this code will change much. Personally, I'd prefer writing this formatting of event in both Java and JS - for both backends separately, or maybe do it on frontend that is shared by both backends. Even if loading a WASM module is quick it can hardly show the effect with this short event formatting stuff. It would be more reasonable for big libraries being loaded.

I'd prefer if someone else could give their opinion as well before merging this.

@rhuss
Copy link

rhuss commented Apr 25, 2023

Thanks, @cardil, for this experiment, it looks interesting and might pave the way for future experimentation with WASM (e.g., how to put a runtime best in the image).

However, I think we should not add this to this showcase image. Let me explain why:

  • We should be clear about the purpose of this image. It's meant to be used as-is in smoke tests or demos, to verify and demonstrate Knative, and maybe also for debugging. So the scope is, by intention, quite limited. It is not meant to be a blueprint for creating showcase-like applications, so the user of this image will not look into the source (at least, this is not the goal). Of course, anybody can look and learn from the source like anybody can look and learn from the Knative backend code. But that is not the intention; we don't optimize for that. Also, the app should not transform into a Swiss army knife or Frankenstein, the art is to stay close to the original focus.
  • The nice thing about container images is that somebody creates them and somebody is using them, so they build an excellent handover point. We care about the users of these images, not about the ones who are creating those (which are mostly us).
  • Since our team (that changes over time) maintains that image, one non-functional goal is to keep the maintenance costs as low as possible for the features it supports. This implies:
    • As few dependencies as possible to avoid rebuilds because of CVEs and other upstream changes.
    • No extra functionality that is not needed for the original use case, especially none that is not visible to the end-user (like a WASM plugin architecture).
    • Optimize by abstraction only if there is a clear benefit for the future. Since I don't expect that showcase to grow much more (and indeed, it shouldn't!), adding such an abstraction here is overkill.

@cardil, sorry that I don't have a more positive answer. I definitely see the value in experimenting and learning new technologies like WASM. Still, only because we have (supposedly) a new golden hammer doesn't mean everything is now a nail. We can consider moving this experimentation to another playground.

One example that I see is to try to get the queue-proxy functionality into a WASM module that can be used as Dapr middleware. I think this is more natural instead of adding a user-invisible addition of implementation details that adds more dependencies (the WASM deps are not even 100% stable, I would guess) and does not have any benefits when it comes to maintenance.

@cardil
Copy link
Member Author

cardil commented May 11, 2023

I'll prepare simpler implementation

/close

@openshift-ci openshift-ci bot closed this May 11, 2023
@openshift-ci
Copy link

openshift-ci bot commented May 11, 2023

@cardil: Closed this PR.

In response to this:

I'll prepare simpler implementation

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@mgencur
Copy link

mgencur commented May 11, 2023

Thanks @cardil

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved kind/enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Received events should be logged in human-readable form
3 participants