Upstreaming of proxy-wasm Part 1.#10262
Conversation
Signed-off-by: John Plevyak <jplevyak@gmail.com>
mattklein123
left a comment
There was a problem hiding this comment.
Flushing out an initial set of questions/comments. Also needs a format fix I think. Thanks for working on this! Very excited to see this land.
| if (it != wasm()->counters_.end()) { | ||
| if (offset > 0) { | ||
| it->second->add(offset); | ||
| return WasmResult::Ok; |
There was a problem hiding this comment.
The coverage build is broken right now, but please make sure all of the C-style error handling this file has full test coverage. I will be checking before merge. Thank you!
There was a problem hiding this comment.
I'll make a coverage pass once we get the first set of reviews done and have resolved any high level changes which might invalidate tests for low level details like error handling conditionals.
Signed-off-by: John Plevyak <jplevyak@gmail.com>
Signed-off-by: John Plevyak <jplevyak@gmail.com>
Signed-off-by: John Plevyak <jplevyak@gmail.com>
Signed-off-by: John Plevyak <jplevyak@gmail.com>
Signed-off-by: John Plevyak <jplevyak@gmail.com>
Signed-off-by: John Plevyak <jplevyak@gmail.com>
Signed-off-by: John Plevyak <jplevyak@gmail.com>
Signed-off-by: John Plevyak <jplevyak@gmail.com>
|
/retest |
|
🤷♀️ nothing to rebuild. |
Signed-off-by: John Plevyak <jplevyak@gmail.com>
There was a problem hiding this comment.
I suspect this is not a great pattern for using StatNameSet; I'm inclined not to institutionalize it by centralizing a shortcut for it.
But it's worth exploring what your data model is. Is the StatNameSet shared across all threads, all VMs?
There was a problem hiding this comment.
Yes. The VMs are running the same code and there are many of them (e.g 60 on a large system), so the replication would be large without sharing.
There was a problem hiding this comment.
There was a problem hiding this comment.
As discussed on envoyproxy/envoy-wasm#452 we have a new solution and are testing this now. I will upstream that change assuming it works out. Let's not let that hold up this review.
|
Is something busted with CI ? The failure that this is reporting doesn't make any sense. It is saying that a constructor requires more arguments than the code very clearly requires. Moreover it compiles for some targets and not for others and it compiles fine on my machine. Also, it started to fail after a pushed a comment change. It had worked before that, so it isn't the code AFAICT |
|
@jplevyak AZP merges master for you. Merge master. Also, stepping back, can you update us on how we are supposed to review this? I'm confused about whether we are waiting on ABI docs, doing reviews in the other repo, etc. Thanks! /wait |
|
The ABI doc: https://github.com/proxy-wasm/spec You can do this review independently if you like. I will be merging the host repo review branch back into master. Then I can do a true-up PR here which will update the host repo SHA after that is fully reviewed. Changes to the ABI will be done in the SDK and host repos first, then integrated here as well. I'll take care of the dependencies, you just review what you feel comfortable with and I'll worry about how to make it all consistent. |
I would like to start with the ABI review as the first thing, and get the most eyes on that. After that, I will take care of the code reviews which hope will move quickly. So given ^ can we make a PR of the ABI spec/headers/whatever like you did for the other code and then we can have a bunch of people review that? |
Signed-off-by: John Plevyak <jplevyak@gmail.com>
@mattklein123 I'll do that later tonight / tomorrow morning (I need to wrap one thing first). Do you want to have a bunch of small PRs of ABI groups (root, http, network, queues, shared data, etc.) or just one big PR? |
I'm fine with 1 big PR, but see proxy-wasm/proxy-wasm-cpp-host#2 (comment). I think we can just do inline docs on that PR? |
Update the host dependency. Move the BUILD files for the proxy-wasm dependencies into envoy external. Signed-off-by: John Plevyak <jplevyak@gmail.com>
Signed-off-by: John Plevyak <jplevyak@gmail.com>
|
cc @lizan ^ our build/bazel expert. |
|
Builds seems OK now, what was the issue? |
|
If we are good with this overall, I will make a coverage pass. |
|
@jplevyak I think it's fine to start a coverage pass but I have not really reviewed this yet. I'm going to review the ABI header/docs this today. |
| */ | ||
| extern "C" WasmResult proxy_get_configuration((uint32_t start, uint32_t length, | ||
| const char** configuration_ptr, size_t* configuration_size); | ||
| enum class WasmBufferType : int32_t { |
There was a problem hiding this comment.
I think that WasmConfigurationBufferType may be easier to interpret.
| package(default_visibility = ["//visibility:public"]) | ||
|
|
||
| cc_library( | ||
| name = "include", |
There was a problem hiding this comment.
I think that name = "proxy_wasm_interface" is better.
| ) | ||
|
|
||
| cc_library( | ||
| name = "lib", |
There was a problem hiding this comment.
name = "proxy_wasm_lib" may be better.
| } | ||
|
|
||
| WasmResult Context::incrementMetric(uint32_t metric_id, int64_t offset) { | ||
| auto type = static_cast<MetricType>(metric_id & Wasm::kMetricTypeMask); |
There was a problem hiding this comment.
It seems that Hungarian notation is not used much in Envoy.
Signed-off-by: John Plevyak <jplevyak@gmail.com>
|
This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
|
This pull request has been automatically closed because it has not had activity in the last 14 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
Signed-off-by: John Plevyak jplevyak@gmail.com
For an explanation of how to fill out the fields, please see the relevant section
in PULL_REQUESTS.md
Description: Upstreaming of proxy-wasm. This is the first of what will be several PRs.
Risk Level: Low
Testing: Unit tests
Docs Changes: N/A
Release Notes: NA/
[Optional Fixes #Issue] partial #4272
[Optional Deprecated:]