generic proxy: move generic proxy from contrib into extensions #34892
Conversation
Signed-off-by: wbpcode <wbphub@live.com>
Signed-off-by: wbpcode <wbphub@live.com>
|
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
Signed-off-by: wbpcode <wbphub@live.com>
| @@ -16,7 +16,7 @@ import "validate/validate.proto"; | |||
| option java_package = "io.envoyproxy.envoy.extensions.filters.network.generic_proxy.action.v3"; | |||
| option java_outer_classname = "ActionProto"; | |||
| option java_multiple_files = true; | |||
| option go_package = "github.com/envoyproxy/go-control-plane/contrib/envoy/extensions/filters/network/generic_proxy/action/v3;actionv3"; | |||
| option go_package = "github.com/envoyproxy/go-control-plane/envoy/extensions/filters/network/generic_proxy/action/v3;actionv3"; | |||
There was a problem hiding this comment.
cc @htuch will this impact go based control planes that provided a contrib?
IMHO as this is contrib it may be ~ok to break, but just wondering whether we should reconsider the impact of moving an extension from contrib to extensions in the future.
There was a problem hiding this comment.
I'm not worried about that since it was contrib (it will have build consequences though).
|
/coverage |
|
Coverage for this Pull Request will be rendered here: https://storage.googleapis.com/envoy-pr/34892/coverage/index.html The coverage results are (re-)rendered each time the CI |
Signed-off-by: wbpcode <wbphub@live.com>
|
/coverage |
|
Coverage for this Pull Request will be rendered here: https://storage.googleapis.com/envoy-pr/34892/coverage/index.html The coverage results are (re-)rendered each time the CI |
Signed-off-by: wbpcode <wbphub@live.com>
Signed-off-by: wbpcode <wbphub@live.com>
|
/retest |
1 similar comment
|
/retest |
Signed-off-by: wbpcode <wbphub@live.com>
…hanks Signed-off-by: wbpcode <wbphub@live.com>
|
It LGTM, but it seems the CI still not happy |
|
/wait |
…ove-generic-proxy
Signed-off-by: wbpcode <wbphub@gmail.com>
|
Just for confirmation, this is normal extension, so I think one approval from maintainer is enough? cc @alyssawilk |
|
Generally I'd say senior maintainer approval for initial import but AFIK you have Matt's thumbs up on slack so yeah I'd say any approval is fine. |
…ove-generic-proxy
envoyproxy#34892)" This reverts commit 0dbd441. Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
|
was prechecks broken prior to this PR? I'm seeing it fail on main now where it wasn't before my last sync, but it could have been a numbe ro fPRs |
Commit Message: generic proxy: move generic proxy from contrib into extensions
Additional Description:
The generic proxy is designed as a framework to empower the developers to develop new L7 proxy for various L7 protocols.
It's be used for multiple different private protocols now in the production env of our users. And recently, I complete the last part of generic proxy: the filter chain support to the variable length stream. And except the private protocols, we use the generic proxy implement the kafka proxing and pulsar proxing and conditional traffic routing. (part of these works are contributed back to the envoy).
After an offline discussion with other maintainers, I prepare to move the generic proxy to the extensions now.
Risk Level: low.
Testing: n/a.
Docs Changes: n/a.
Release Notes: n/a.
Platform Specific Features: n/a.