text:
Envoy on Apple silicon m1

Title: Envoy on Apple silicon m1
Hi
I am trying to get Knative with Istio(or any other Ingress controller based on Envoy) running on a Mac mini with the Apple Silicon m1 chip. And I am told that Istio is not working do to Envoy not supporting Apple m1 chip.
Description:
A working setup on Kubernetes running Istio(Envoy)

cc @ggreenway who may know more about any toolchain issues preventing build for m1's

Istio / arm is not supported
https://github.com/istio/istio/issues/32751#issuecomment-837235830
Envoy not supporting arm?
https://github.com/istio/istio/issues/29596
https://github.com/istio/istio/issues/21094

It's on my TODO list to investigate building envoy for m1, but I don't know when I'll get to it. If someone else wants to take it up, go for it.

One of the challenges is availability of VMs with m1 silicon or physical hardware to test on.

I've heard that we could get a single m1 instance for the OSS project from https://www.macstadium.com/opensource. It might be enough to setup a periodic build off of main to post-facto check for breakages. Also on my TODO list to look into.

My m1 Mac Mini arrived last night (16GB RAM) and I've got the development environment set up, full xcode installed, the brand new m1 native bazel 4.1.0 etc. ~/.bazelrc is:
build --announce_rc
build --define deprecated_features=disabled
build --define disable_object_dump_on_signal_trace=disabled
build --define google_grpc=disabled
build --define path_normalization_by_default=true
build --define quiche=enabled
build --define signal_trace=disabled
build --define tcmalloc=disabled
build --define wasm=disabled
build --define zlib=ng
build --override_repository=envoy_build_config=/Users/<username>/Applications/envoy/build

I'm getting the following error on the first thing the process tries to compile. The xcode-locator tool it uses isn't m1 compatible even though I've installed the Darwin arm64 Bazel package.
ERROR: /private/var/tmp/_bazel_<username>/3335c71f4281d4576473beb63d032778/external/envoy/bazel/foreign_cc/BUILD:345:12: CcCmakeMakeRule external/envoy/bazel/foreign_cc/zlib/include failed: I/O exception during sandboxed execution: com.google.devtools.build.lib.shell.ExecFailedException: java.io.IOException: Cannot run program "/var/tmp/_bazel_<username>/install/d0b631b3e5a643567f221e133629d965/xcode-locator": error=86, Bad CPU type in executable

Now wondering if I should try getting the m1 compatible Azul JDK and building Bazel from source?

I now have a working binary on Apple Silicon. My goal was to not have to install Rosetta:

Darwin arm64 Bazel 4.1.0 didn't work and tries to use non-Apple silicon binaries like xcode-locator that won't run
After some trial and error I ended up building Bazel 4.1.0 from source after installing Apple silicon capable Azul JDK
Azul JDK 15 worked - https://www.azul.com/downloads/?version=java-15-mts&os=macos&architecture=arm-64-bit&package=jdk
Bazel needs to be patched - https://github.com/bazelbuild/bazel/commit/0216ee54417fa1f2fef14f6eb14cbc1e8f595821
Build Bazel with env EXTRA_BAZEL_ARGS="--host_javabase=@local_jdk//:jdk" ./compile.sh

This compilation worked and produced a binary that wouldn't run generating a SIGKILL. Using lldb I could see the following error:
lldb ./envoy
(lldb) target create "./envoy"
Current executable set to '/Users/<username>/Applications/envoy/envoy' (arm64).
(lldb) process launch
error: Malformed Mach-o file

That lead me to - https://github.com/wg/wrk/issues/448
 bazel/envoy_binary.bzl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bazel/envoy_binary.bzl b/bazel/envoy_binary.bzl
index 43c52bf7e..3bd40e35d 100644
--- a/bazel/envoy_binary.bzl
+++ b/bazel/envoy_binary.bzl
@@ -57,8 +57,8 @@ def _envoy_linkopts():
         # The macOS system library transitively links common libraries (e.g., pthread).
         "@envoy//bazel:apple": [
             # See note here: https://luajit.org/install.html
-            "-pagezero_size 10000",
-            "-image_base 100000000",
+          # "-pagezero_size 10000",
+          # "-image_base 100000000",
         ],
         "@envoy//bazel:windows_opt_build": [
             "-DEFAULTLIB:ws2_32.lib",

This will need to be updated with correct logic.
Lastly I don't know if this is required:
 bazel/BUILD | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bazel/BUILD b/bazel/BUILD
index 98be980f8..66f2e364d 100644
--- a/bazel/BUILD
+++ b/bazel/BUILD
@@ -540,6 +540,7 @@ selects.config_setting_group(
     name = "apple",
     match_any = [
         ":darwin",
+        ":darwin_arm64",
         ":darwin_x86_64",
         ":ios_arm64",
         ":ios_arm64e",

Success!

That is super cool work!!!

Hi @ggreenway did you see @moderation comments?

Hi, I tried building the latest codebase using the patch suggested above. Although that did get me further than before I'm now seeing the following error on M1
Use --sandbox_debug to see verbose messages from the sandbox
compilepkg: missing strict dependencies:
	/private/var/tmp/_bazel_xyz/90f305687f37d42ba5f4826d49344d1b/sandbox/darwin-sandbox/117/execroot/envoy/external/com_github_lyft_protoc_gen_star/init_option.go: import of "github.com/spf13/afero"
	/private/var/tmp/_bazel_xyz/90f305687f37d42ba5f4826d49344d1b/sandbox/darwin-sandbox/117/execroot/envoy/external/com_github_lyft_protoc_gen_star/persister.go: import of "github.com/spf13/afero"
No dependencies were provided.

I'm using the latest bazel to build envoy and ran bazel build source/exe:envoy

Also, if anyone is able to build envoy on arm64 (as suggested on this issue), can you please share the binary so others can try it out?

@vinayreddy are you talking about M1 arm64 specifically or just arm64?  There are arm64 images at https://hub.docker.com/r/envoyproxy/envoy/tags?page=1&ordering=last_updated.  This is Ok if you have Docker. There are some hacky script ways to extract the binary from the images
I'm building on M1 but I compile out a bunch of extensions and you probably shouldn't trust a binary from random people on the internet 😀

Yes, I was talking M1 arm64. Yes, I was able to run a docker image on my M1 mac, so that is something I can use to make progress.
Haha, fair point that I shouldn't run random binaries I find on the Internet.

@vinayreddy good that you have an image running on your M1. I think today the only way to get an M1 Apple Silicon binary, that can run without Rosetta or virtualization like Docker, is the process I outlined at https://github.com/envoyproxy/envoy/issues/16482#issuecomment-846439439

Does someone have resources and build skills to implement what @moderation said above? There's considerable tech debt relying on translation as for example you have to consider the intent when this is eventually addressed. The longer this takes to resolve the more ecosystem cleanup will be needed.

@JCzz did you close this by accident? it isn't obvious what fixed it..

@keith just as a try. this isn't resolved and one issue we have in homebrew is that few of the envoy dimensions work. Notably, many have apple silicon at this point and while possible to use rossetta 2, it seems like if some effort started on arm64 support for mac, it might finish, but if nothing starts and this stays closed it will never resolve.

I'm not really sure what is required here but I will mark this help wanted.

this comment should probably be pinned https://github.com/envoyproxy/envoy/issues/16482#issuecomment-846439439 🤞 someone with apple silicon can pass the build and get a PR up

Ok I did some light testing here building on a M1 for the M1 CPU and discovered a few issues:

golang has to be updated to versions that support m1, which also required some rules updates (specifically for gazelle) https://github.com/envoyproxy/envoy/pull/17438
it seems like when using the darwin-sandbox strategy (which envoy uses by default) this issue https://github.com/bazelbuild/bazel/issues/7448 causes rules_foreign_cc to fail in some cases because it cannot discover the correct headers, I'm still trying to determine if this was a real issue, or a red herring
for some reason the gperftools build doesn't produce the right static library, I ignored this for now with --define=tcmalloc=disabled (envoy-mobile disables this when building for iOS as well but I don't recall why, might be related)
the /usr/local/* paths used by homebrew of the past likely now only contain x86_64 libraries that envoy relies on, so I have been passing --action_env=PATH=/opt/homebrew/bin:/usr/bin:/bin to use the correct brew path (I'm also not sure if passing --linkopt=-L/opt/homebrew/bin is required, but I have been testing with that "just in case")
https://github.com/bazelbuild/rules_foreign_cc/issues/672 this seems to still be an issue, I avoided it by using the system installations I have instead
https://github.com/envoyproxy/envoy/pull/17444
rules_foreign_cc had to be updated, details on https://github.com/envoyproxy/envoy/pull/17445

Looks like we can remove the luajit workarounds that had to be commented out above https://github.com/envoyproxy/envoy/pull/17466/

Fix for https://github.com/bazelbuild/rules_foreign_cc/issues/672 https://github.com/envoyproxy/envoy/pull/17467 (and I think it's a nice UX improvement)

Looks like Bazel 4.2.0 has resolved the M1 issues above and I was able to run the full and no JDK versions without issue - https://github.com/bazelbuild/bazel/releases/tag/4.2.0

https://github.com/envoyproxy/envoy/pull/17460 is actually the PR to hope for now since it turns out updating go requires these new proto annotations everywhere, so that linked PR is part of this

thank you @keith. I really look forward to not having to explain lack of arm64 on homebrew every time. Seems like not too much longer now.

Seems like something regressed and now chromium fails to build with:
FAILED: bytecode_builtins_list_generator
python3 "../../build/toolchain/gcc_link_wrapper.py" --output="./bytecode_builtins_list_generator" -- clang++ -fuse-ld=lld -Wl,-fatal_warnings -Wl,--color-diagnostics -stdlib=libc++ -arch arm64 -no-canonical-prefixes -Werror -isysroot ../../../../../../../../../Applications/Xcode-13.0.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk -mmacosx-version-min=10.11.0 -Wl,-ObjC -Wl,-dead_strip -o "./bytecode_builtins_list_generator"  @"./bytecode_builtins_list_generator.rsp"
clang++: error: invalid linker name in argument '-fuse-ld=lld'

Where lld cannot be used on macOS with the Xcode toolchain right now.

Fix here https://github.com/envoyproxy/envoy/pull/18922

Here's another improvement for everyone, but previously was only blocked by M1 support https://github.com/envoyproxy/envoy/pull/19072

Ok the long running rules_go / golang update landed https://github.com/envoyproxy/envoy/pull/17460 so we'll have to test end to end again but I think the previously known blockers are all resolved!

Alright I just tested a bazel build envoy on my M1 machine and it works end to end! That doesn't cover all possible configurations, but it's still a good sign. @codefromthecrypt can you build your other configurations and see if any new issues come up?

@keith should we update rules_go from 0.27.0 to 0.29.0 to unblock M1 build support?

We're on 0.28 now, it landed as part of that PR above
https://github.com/envoyproxy/envoy/blob/70a5f295da789610b9d078015f43e39c6a76d4b6/bazel/repository_locations.bzl#L654
I think we're unblocked here, post here if you see issues

thanks for the progress @keith. The goal isn't so much me working, but homebrew working (#17500). I won't have time to resolve all the issues, but I can share where things are right now.
Firstly, while envoy's build requires git (#2181), you need a git tag in order to test whether homebrew works or not. (cc @carlocab in case I am mistaken) Anyway, as that seems to be the case, and I don't have karma to push a tag, I made a fork and pushed a tag for the latest commit, then updated my local copy of envoy.rb to point to that.
Ex. this is what to change
$ cd /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/
$ git diff Formula/envoy.rb
diff --git a/Formula/envoy.rb b/Formula/envoy.rb
index ce4a24d6d6a..94760519a70 100644
--- a/Formula/envoy.rb
+++ b/Formula/envoy.rb
@@ -3,9 +3,9 @@ class Envoy < Formula
   homepage "https://www.envoyproxy.io/index.html"
   # Switch to a tarball when the following issue is resolved:
   # https://github.com/envoyproxy/envoy/issues/2181
-  url "https://github.com/envoyproxy/envoy.git",
-      tag:      "v1.20.1",
-      revision: "ea23f47b27464794980c05ab290a3b73d801405e"
+  url "https://github.com/codefromthecrypt/envoy.git",
+      tag:      "v1.21.0",
+      revision: "8a9779a615afebbff8b765d3fdd99c8c0c818591"
   license "Apache-2.0"

   # Apple M1/arm64 is pending envoyproxy/envoy#16482

Next, try brew install --build-from-source envoy. This failed for reasons probably someone else can diagnose better than me. Hope these instructions help!
$ brew install --build-from-source envoy
==> Downloading https://ghcr.io/v2/homebrew/core/cmake/manifests/3.22.0
Already downloaded: /Users/thebots/Library/Caches/Homebrew/downloads/0e6c1beadc6246cd1a5760e035b71640ac5673ffbee411d0c696f7c4a40aae96--cmake-3.22.0.bottle_manifest.json
==> Downloading https://ghcr.io/v2/homebrew/core/cmake/blobs/sha256:2ecfdea833356807af17016cd40db4d51f04ad6c00479e
Already downloaded: /Users/thebots/Library/Caches/Homebrew/downloads/ac6eeaf46044bb24578718e225345f6294fb35fb3f2faa73f188a6d4d736cb92--cmake--3.22.0.arm64_monterey.bottle.tar.gz
==> Downloading https://ghcr.io/v2/homebrew/core/ninja/manifests/1.10.2_1
Already downloaded: /Users/thebots/Library/Caches/Homebrew/downloads/3d885b06ee8943649e1e4f3edebcca2003dc2e9e332202cc2a0b16ccce4f8cae--ninja-1.10.2_1.bottle_manifest.json
==> Downloading https://ghcr.io/v2/homebrew/core/ninja/blobs/sha256:8efac5a9c8b7028f64f5a092eb029ff40887b9895fe423
Already downloaded: /Users/thebots/Library/Caches/Homebrew/downloads/deb592b6fb7dd715b57a170608e055406d978bbc68c284ffa7ecef67acef899a--ninja--1.10.2_1.arm64_monterey.bottle.tar.gz
==> Cloning https://github.com/codefromthecrypt/envoy.git
Updating /Users/thebots/Library/Caches/Homebrew/envoy--git
From https://github.com/codefromthecrypt/envoy
 * [new tag]             v1.21.0    -> v1.21.0
==> Checking out tag v1.21.0
Previous HEAD position was 96701cb24 docs: fixes for release notes for 1.20 (#18403)
HEAD is now at 8a9779a61 build(deps): bump setuptools from 59.0.1 to 59.5.0 in /tools/base (#19201)
HEAD is now at 8a9779a61 build(deps): bump setuptools from 59.0.1 to 59.5.0 in /tools/base (#19201)
Error: v1.21.0 tag should be 9d5627a0879b0a029e90515137c108e1d2884bfc
but is actually 8a9779a615afebbff8b765d3fdd99c8c0c818591
MacBook-Air:homebrew thebots$ vi ./Library/Taps/homebrew/homebrew-core/Formula/envoy.rb
MacBook-Air:homebrew thebots$ brew install --build-from-source envoy
==> Downloading https://ghcr.io/v2/homebrew/core/cmake/manifests/3.22.0
Already downloaded: /Users/thebots/Library/Caches/Homebrew/downloads/0e6c1beadc6246cd1a5760e035b71640ac5673ffbee411d0c696f7c4a40aae96--cmake-3.22.0.bottle_manifest.json
==> Downloading https://ghcr.io/v2/homebrew/core/cmake/blobs/sha256:2ecfdea833356807af17016cd40db4d51f04ad6c00479e
Already downloaded: /Users/thebots/Library/Caches/Homebrew/downloads/ac6eeaf46044bb24578718e225345f6294fb35fb3f2faa73f188a6d4d736cb92--cmake--3.22.0.arm64_monterey.bottle.tar.gz
==> Downloading https://ghcr.io/v2/homebrew/core/ninja/manifests/1.10.2_1
Already downloaded: /Users/thebots/Library/Caches/Homebrew/downloads/3d885b06ee8943649e1e4f3edebcca2003dc2e9e332202cc2a0b16ccce4f8cae--ninja-1.10.2_1.bottle_manifest.json
==> Downloading https://ghcr.io/v2/homebrew/core/ninja/blobs/sha256:8efac5a9c8b7028f64f5a092eb029ff40887b9895fe423
Already downloaded: /Users/thebots/Library/Caches/Homebrew/downloads/deb592b6fb7dd715b57a170608e055406d978bbc68c284ffa7ecef67acef899a--ninja--1.10.2_1.arm64_monterey.bottle.tar.gz
==> Cloning https://github.com/codefromthecrypt/envoy.git
Updating /Users/thebots/Library/Caches/Homebrew/envoy--git
==> Checking out tag v1.21.0
HEAD is now at 8a9779a61 build(deps): bump setuptools from 59.0.1 to 59.5.0 in /tools/base (#19201)
HEAD is now at 8a9779a61 build(deps): bump setuptools from 59.0.1 to 59.5.0 in /tools/base (#19201)
==> Installing dependencies for envoy: cmake and ninja
==> Installing envoy dependency: cmake
==> Pouring cmake--3.22.0.arm64_monterey.bottle.tar.gz
🍺  /opt/homebrew/Cellar/cmake/3.22.0: 2,986 files, 41.6MB
==> Installing envoy dependency: ninja
==> Pouring ninja--1.10.2_1.arm64_monterey.bottle.tar.gz
🍺  /opt/homebrew/Cellar/ninja/1.10.2_1: 10 files, 388KB
==> Installing envoy
==> /opt/homebrew/opt/bazelisk/bin/bazelisk build --compilation_mode=opt --curses=no --show_task_finish --verbose_
Last 15 lines from /Users/thebots/Library/Logs/Homebrew/envoy/01.bazelisk:
Analyzing: target //source/exe:envoy-static (20 packages loaded, 7 targets configured)
Analyzing: target //source/exe:envoy-static (20 packages loaded, 7 targets configured)
Analyzing: target //source/exe:envoy-static (20 packages loaded, 7 targets configured)
Analyzing: target //source/exe:envoy-static (20 packages loaded, 7 targets configured)
Analyzing: target //source/exe:envoy-static (20 packages loaded, 7 targets configured)
Analyzing: target //source/exe:envoy-static (20 packages loaded, 7 targets configured)
ERROR: /private/tmp/envoy-20211207-61335-aduab4/.brew_home/_bazel/dd0c3ef926b0a56f33d0ac8f5e25816a/external/local_config_cc/BUILD:48:19: in cc_toolchain_suite rule @local_config_cc//:toolchain: cc_toolchain_suite '@local_config_cc//:toolchain' does not contain a toolchain for cpu 'darwin_arm64'
ERROR: While resolving configuration keys for //bazel:gcc_build: Analysis of target '@local_config_cc//:toolchain' failed
ERROR: While resolving configuration keys for //source/exe:envoy-static: Analysis of target '@local_config_cc//:toolchain' failed
ERROR: Analysis of target '//source/exe:envoy-static' failed; build aborted: Analysis of target '@local_config_cc//:toolchain' failed
INFO: Elapsed time: 59.529s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (34 packages loaded, 202 targets configured)
FAILED: Build did NOT complete successfully (34 packages loaded, 202 targets configured)

READ THIS: https://docs.brew.sh/Troubleshooting

Thanks for testing, I've submitted https://github.com/Homebrew/homebrew-core/pull/90601 which allows you to do brew install --build-from-source envoy --HEAD which helps test this more easily.
Is your host an M1 mac? Do you have a full installation of Xcode vs only the command line tools?

I tested on my m1 mac.
❯ bazel build envoy
Starting local Bazel server and connecting to it...
INFO: SHA256 (https://golang.org/dl/?mode=json&include=all) = dd71d0c702dbeb9a765da037c9792250fb9e440fa3bd5dbdca91db34f0265446
WARNING: Download from https://golang.org/dl/?mode=json&include=all failed: class java.io.IOException connect timed out
INFO: Analyzed target //:envoy (714 packages loaded, 43880 targets configured).
INFO: Found 1 target...
INFO: From Executing genrule @com_lightstep_tracer_cpp//:generate_version_h:
CMake Warning at CMakeLists.txt:74 (message):
  WITH_GRPC is not set; building without dynamic loading support.

-- The C compiler identification is AppleClang 13.0.0.13000029
-- The CXX compiler identification is AppleClang 13.0.0.13000029
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /var/folders/c5/rm398s_d2vs03cf07wqpr8dr0000gn/T/tmp.1sF7Wwfb
-- Cache values
BUILD_SHARED_LIBS:BOOL=ON
BUILD_STATIC_LIBS:BOOL=ON
CMAKE_BUILD_TYPE:STRING=
CMAKE_INSTALL_PREFIX:PATH=/usr/local
CMAKE_OSX_ARCHITECTURES:STRING=
CMAKE_OSX_DEPLOYMENT_TARGET:STRING=
CMAKE_OSX_SYSROOT:PATH=/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk
DEFAULT_SSL_ROOTS_PEM:STRING=
HEADERS_ONLY:BOOL=ON
WITH_CARES:BOOL=OFF
WITH_DYNAMIC_LOAD:BOOL=ON
WITH_GRPC:BOOL=OFF
WITH_LIBEVENT:BOOL=OFF
ERROR: /private/var/tmp/_bazel_patrick/8c59177cb250ffabcb42d9e36319c1f2/external/envoy/bazel/foreign_cc/BUILD:68:15: Foreign Cc - Configure: Building luajit failed: (Exit 1): bash failed: error executing command /bin/bash -c bazel-out/darwin_arm64-fastbuild/bin/external/envoy/bazel/foreign_cc/luajit_foreign_cc/wrapper_build_script.sh

Use --sandbox_debug to see verbose messages from the sandbox
rules_foreign_cc: Build failed!
rules_foreign_cc: Keeping temp build directory and dependencies directory for debug.
rules_foreign_cc: Please note that the directories inside a sandbox are still cleaned unless you specify --sandbox_debug Bazel command line flag.
rules_foreign_cc: Printing build logs:
_____ BEGIN BUILD LOGS _____

Bazel external C/C++ Rules. Building library luajit

xcrun: error: SDK "macosx12.0" cannot be located
xcrun: error: SDK "macosx12.0" cannot be located
xcrun: error: unable to lookup item 'Path' in SDK 'macosx12.0'
_____ END BUILD LOGS _____
rules_foreign_cc: Build wrapper script location: bazel-out/darwin_arm64-fastbuild/bin/external/envoy/bazel/foreign_cc/luajit_foreign_cc/wrapper_build_script.sh
rules_foreign_cc: Build script location: bazel-out/darwin_arm64-fastbuild/bin/external/envoy/bazel/foreign_cc/luajit_foreign_cc/build_script.sh
rules_foreign_cc: Build log location: bazel-out/darwin_arm64-fastbuild/bin/external/envoy/bazel/foreign_cc/luajit_foreign_cc/Configure.log

Target //source/exe:envoy-static failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 249.425s, Critical Path: 6.18s
INFO: 1752 processes: 1717 internal, 35 darwin-sandbox.
FAILED: Build did NOT complete successfully

@keith I fixed the above problem by sudo xcode-select --switch /Applications/Xcode.app. And It has built successfully. GOOD JOB!! THKS!!

@carlocab (but anyone can answer) do you know if there's a way to avoid
explicit settings like above? Seems we want to avoid configuration, ideally
zero.
On Tue, Dec 7, 2021 at 4:01 PM 白泽 @.***> wrote:

@keith https://github.com/keith I fixed the above problem by sudo
xcode-select --switch /Applications/Xcode.app. And It has built
successfully. GOOD JOB!! THKS!!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/envoyproxy/envoy/issues/16482#issuecomment-987664829,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAPVV5MIBYY3PPQYNXGVWDUPW5PJANCNFSM442RLFUQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

@codefromthecrypt The need to install XCODE and configure it correctly is probably unavoidable. Fortunately, the configuration is correct after installed XCODE in normal.

@Patrick0308 would you happen to know what xcode-select --print-path was before you did xcode-select --switch?

@carlocab Sorry, I didn't print the PATH of the active developer directory before did xcode-select --switch. What I know is that before I did bazel build bazel that I updated my XCODE.
If I did sudo xcode-select --switch /Library/Developer/CommandLineTools, there are something wrong when building enovy.
❯ bazel build envoy
INFO: Analyzed target //:envoy (1 packages loaded, 16986 targets configured).
INFO: Found 1 target...
ERROR: /private/var/tmp/_bazel_patrick/8c59177cb250ffabcb42d9e36319c1f2/external/com_googlesource_chromium_v8/BUILD.bazel:33:8: Executing genrule @com_googlesource_chromium_v8//:build failed: (Exit 1): bash failed: error executing command /bin/bash -c ... (remaining 1 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox
/private/var/tmp/_bazel_patrick/8c59177cb250ffabcb42d9e36319c1f2/sandbox/darwin-sandbox/5978/execroot/envoy/external/com_googlesource_chromium_v8 /private/var/tmp/_bazel_patrick/8c59177cb250ffabcb42d9e36319c1f2/sandbox/darwin-sandbox/5978/execroot/envoy
ERROR at //build/config/mac/mac_sdk.gni:92:19: Script returned non-zero exit code.
_mac_sdk_result = exec_script(script_name, sdk_info_args, "scope")
                  ^----------
Current dir: /private/var/tmp/_bazel_patrick/8c59177cb250ffabcb42d9e36319c1f2/sandbox/darwin-sandbox/5978/execroot/envoy/external/com_googlesource_chromium_v8/out/wee8/
Command: python3 /private/var/tmp/_bazel_patrick/8c59177cb250ffabcb42d9e36319c1f2/sandbox/darwin-sandbox/5978/execroot/envoy/external/com_googlesource_chromium_v8/build/config/apple/sdk_info.py macosx
Returned 1.
stderr:

xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
Traceback (most recent call last):
  File "/private/var/tmp/_bazel_patrick/8c59177cb250ffabcb42d9e36319c1f2/sandbox/darwin-sandbox/5978/execroot/envoy/external/com_googlesource_chromium_v8/build/config/apple/sdk_info.py", line 167, in <module>
    FillXcodeVersion(settings, args.developer_dir)
  File "/private/var/tmp/_bazel_patrick/8c59177cb250ffabcb42d9e36319c1f2/sandbox/darwin-sandbox/5978/execroot/envoy/external/com_googlesource_chromium_v8/build/config/apple/sdk_info.py", line 80, in FillXcodeVersion
    lines = subprocess.check_output(['xcodebuild',
  File "/opt/homebrew/Cellar/python@3.9/3.9.9/Frameworks/Python.framework/Versions/3.9/lib/python3.9/subprocess.py", line 424, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "/opt/homebrew/Cellar/python@3.9/3.9.9/Frameworks/Python.framework/Versions/3.9/lib/python3.9/subprocess.py", line 528, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['xcodebuild', '-version']' returned non-zero exit status 1.

See //build/config/sysroot.gni:71:5: whence it was imported.
    import("//build/config/mac/mac_sdk.gni")
    ^--------------------------------------
See //build/config/BUILDCONFIG.gn:410:23: which caused the file to be included.
  _linker_configs = [ "//build/config/mac:strip_all" ]
                      ^-----------------------------
Target //source/exe:envoy-static failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 4.012s, Critical Path: 1.80s
INFO: 3 processes: 3 internal.
FAILED: Build did NOT complete successfully

Ah. Chromium. The formula probably needs a
depends_on xcode: :build

ok trying it on both my Macs prior to marking ready for review. 🤞 and thanks folks. seems we're nearly there (pending an envoy release) https://github.com/Homebrew/homebrew-core/pull/90695

The error is now improved, if full Xcode isn't installed. Thanks for figuring this out @Patrick0308 and thanks for the config tip @carlocab!
$ brew install --build-from-source envoy --HEAD
envoy: A full installation of Xcode.app is required to compile
this software. Installing just the Command Line Tools is not sufficient.

Xcode can be installed from the App Store.
Error: envoy: An unsatisfied requirement failed this build.

I almost did nothing except bazel clean. But I built failed again.
/private/var/tmp/_bazel_patrick/8c59177cb250ffabcb42d9e36319c1f2/sandbox/darwin-sandbox/1192/execroot/envoy/external/local_config_cc/wrapped_clang  -O2 -fomit-frame-pointer -Wall  -DLUAJIT_ENABLE_LUA52COMPAT  -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U_FORTIFY_SOURCE  -DLUA_ROOT=\"/private/var/tmp/_bazel_patrick/8c59177cb250ffabcb42d9e36319c1f2/sandbox/darwin-sandbox/1192/execroot/envoy/bazel-out/darwin_arm64-fastbuild/bin/external/envoy/bazel/foreign_cc/luajit.build_tmpdir/luajit\" -DLUA_MULTILIB=\"lib\" -fno-stack-protector  -D_FORTIFY_SOURCE=1 -fstack-protector -fcolor-diagnostics -Wall -Wthread-safety -Wself-assign -fno-omit-frame-pointer -O0 -DDEBUG DEBUG_PREFIX_MAP_PWD=. -isysroot __BAZEL_XCODE_SDKROOT__ -F__BAZEL_XCODE_SDKROOT__/System/Library/Frameworks -F__BAZEL_XCODE_DEVELOPER_DIR__/Platforms/MacOSX.platform/Developer/Library/Frameworks -mmacosx-version-min=12.0 -no-canonical-prefixes -Wno-builtin-macro-redefined -D__DATE__=redacted -D__TIMESTAMP__=redacted -D__TIME__=redacted -target arm64-apple-macosx -fno-function-sections -fno-data-sections -c -o luajit.o luajit.c
HOSTLINK  host/minilua
/private/var/tmp/_bazel_patrick/8c59177cb250ffabcb42d9e36319c1f2/sandbox/darwin-sandbox/1192/execroot/envoy/external/local_config_cc/wrapped_clang  -lc++ -fobjc-link-runtime -headerpad_max_install_names -no-canonical-prefixes -target arm64-apple-macosx -mmacosx-version-min=12.0   -o host/minilua host/minilua.o -lm
ld: warning: ignoring file host/minilua.o, building for macOS-arm64 but attempting to link with file built for unknown-x86_64
Undefined symbols for architecture arm64:
  "_main", referenced from:
     implicit entry/start for main executable
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Error in child process '/usr/bin/xcrun'. 1
make[1]: *** [host/minilua] Abort trap: 6
make: *** [src/luajit] Error 2
+ set +x
cp: /private/var/tmp/_bazel_patrick/8c59177cb250ffabcb42d9e36319c1f2/sandbox/darwin-sandbox/1192/execroot/envoy/bazel-out/darwin_arm64-fastbuild/bin/external/envoy/bazel/foreign_cc/luajit.build_tmpdir/luajit: No such file or directory
_____ END BUILD LOGS _____
rules_foreign_cc: Build wrapper script location: bazel-out/darwin_arm64-fastbuild/bin/external/envoy/bazel/foreign_cc/luajit_foreign_cc/wrapper_build_script.sh
rules_foreign_cc: Build script location: bazel-out/darwin_arm64-fastbuild/bin/external/envoy/bazel/foreign_cc/luajit_foreign_cc/build_script.sh
rules_foreign_cc: Build log location: bazel-out/darwin_arm64-fastbuild/bin/external/envoy/bazel/foreign_cc/luajit_foreign_cc/Configure.log

Target //source/exe:envoy-static failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 433.514s, Critical Path: 216.65s
INFO: 3005 processes: 1726 internal, 1278 darwin-sandbox, 1 worker.
FAILED: Build did NOT complete successfully

After installing, switching to, and accepting the license of full Xcode, the current main branch works for me on my M1 laptop!
Looking forward to 1.21 as it will allow homebrew to remove the arm64 exception!
$ brew install --HEAD envoy
==> Cloning https://github.com/envoyproxy/envoy.git
Updating /Users/thebots/Library/Caches/Homebrew/envoy--git
==> Checking out branch main
Already on 'main'
Your branch is up to date with 'origin/main'.
HEAD is now at e246aec1d Update presubmit.yml for Bazel CI (#19197)
==> /opt/homebrew/opt/bazelisk/bin/bazelisk build --compilation_mode=opt --curses=no --show_task_finish --verbose_failures --action_

🍺  /opt/homebrew/Cellar/envoy/HEAD-e246aec: 321 files, 92.6MB, built in 33 minutes 4 seconds
==> Running `brew cleanup envoy`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).

$ envoy --version

envoy  version: e246aec1d8e84b7c99402c7b15f34e04088347b1/1.21.0-dev/Modified/RELEASE/BoringSSL

$ brew test --HEAD envoy
==> Testing envoy
[2021-12-08 20:47:28.509][177845][info][main] [source/server/server.cc:381] initializing epoch 0 (base id=0, hot restart version=disabled)
[2021-12-08 20:47:28.510][177845][info][main] [source/server/server.cc:383] statically linked extensions:
[2021-12-08 20:47:28.510][177845][info][main] [source/server/server.cc:385]   envoy.access_loggers: envoy.access_loggers.file, envoy.access_loggers.http_grpc, envoy.access_loggers.open_telemetry, envoy.access_loggers.stderr, envoy.access_loggers.stdout, envoy.access_loggers.tcp_grpc, envoy.access_loggers.wasm, envoy.file_access_log, envoy.http_grpc_access_log, envoy.open_telemetry_access_log, envoy.stderr_access_log, envoy.stdout_access_log, envoy.tcp_grpc_access_log, envoy.wasm_access_log
[2021-12-08 20:47:28.510][177845][info][main] [source/server/server.cc:385]   envoy.request_id: envoy.request_id.uuid
[2021-12-08 20:47:28.510][177845][info][main] [source/server/server.cc:385]   envoy.upstream_options: envoy.extensions.upstreams.http.v3.HttpProtocolOptions, envoy.upstreams.http.http_protocol_options
[2021-12-08 20:47:28.510][177845][info][main] [source/server/server.cc:385]   envoy.compression.decompressor: envoy.compression.brotli.decompressor, envoy.compression.gzip.decompressor
[2021-12-08 20:47:28.510][177845][info][main] [source/server/server.cc:385]   envoy.retry_priorities: envoy.retry_priorities.previous_priorities
[2021-12-08 20:47:28.510][177845][info][main] [source/server/server.cc:385]   envoy.grpc_credentials: envoy.grpc_credentials.aws_iam, envoy.grpc_credentials.default, envoy.grpc_credentials.file_based_metadata
[2021-12-08 20:47:28.510][177845][info][main] [source/server/server.cc:385]   envoy.transport_sockets.downstream: envoy.transport_sockets.alts, envoy.transport_sockets.quic, envoy.transport_sockets.raw_buffer, envoy.transport_sockets.starttls, envoy.transport_sockets.tap, envoy.transport_sockets.tcp_stats, envoy.transport_sockets.tls, raw_buffer, starttls, tls
[2021-12-08 20:47:28.510][177845][info][main] [source/server/server.cc:385]   envoy.filters.http: envoy.bandwidth_limit, envoy.buffer, envoy.cors, envoy.csrf, envoy.ext_authz, envoy.ext_proc, envoy.fault, envoy.filters.http.adaptive_concurrency, envoy.filters.http.admission_control, envoy.filters.http.alternate_protocols_cache, envoy.filters.http.aws_lambda, envoy.filters.http.aws_request_signing, envoy.filters.http.bandwidth_limit, envoy.filters.http.buffer, envoy.filters.http.cache, envoy.filters.http.cdn_loop, envoy.filters.http.composite, envoy.filters.http.compressor, envoy.filters.http.cors, envoy.filters.http.csrf, envoy.filters.http.decompressor, envoy.filters.http.dynamic_forward_proxy, envoy.filters.http.dynamo, envoy.filters.http.ext_authz, envoy.filters.http.ext_proc, envoy.filters.http.fault, envoy.filters.http.grpc_http1_bridge, envoy.filters.http.grpc_http1_reverse_bridge, envoy.filters.http.grpc_json_transcoder, envoy.filters.http.grpc_stats, envoy.filters.http.grpc_web, envoy.filters.http.header_to_metadata, envoy.filters.http.health_check, envoy.filters.http.ip_tagging, envoy.filters.http.jwt_authn, envoy.filters.http.local_ratelimit, envoy.filters.http.lua, envoy.filters.http.oauth2, envoy.filters.http.on_demand, envoy.filters.http.original_src, envoy.filters.http.ratelimit, envoy.filters.http.rbac, envoy.filters.http.router, envoy.filters.http.set_metadata, envoy.filters.http.tap, envoy.filters.http.wasm, envoy.grpc_http1_bridge, envoy.grpc_json_transcoder, envoy.grpc_web, envoy.health_check, envoy.http_dynamo_filter, envoy.ip_tagging, envoy.local_rate_limit, envoy.lua, envoy.rate_limit, envoy.router, match-wrapper
[2021-12-08 20:47:28.511][177845][info][main] [source/server/server.cc:385]   envoy.bootstrap: envoy.bootstrap.wasm, envoy.extensions.network.socket_interface.default_socket_interface
[2021-12-08 20:47:28.512][177845][info][main] [source/server/server.cc:385]   envoy.dubbo_proxy.protocols: dubbo
[2021-12-08 20:47:28.512][177845][info][main] [source/server/server.cc:385]   envoy.rbac.matchers: envoy.rbac.matchers.upstream_ip_port
[2021-12-08 20:47:28.512][177845][info][main] [source/server/server.cc:385]   envoy.formatter: envoy.formatter.metadata, envoy.formatter.req_without_query
[2021-12-08 20:47:28.512][177845][info][main] [source/server/server.cc:385]   envoy.resource_monitors: envoy.resource_monitors.fixed_heap, envoy.resource_monitors.injected_resource
[2021-12-08 20:47:28.512][177845][info][main] [source/server/server.cc:385]   envoy.filters.listener: envoy.filters.listener.http_inspector, envoy.filters.listener.original_dst, envoy.filters.listener.original_src, envoy.filters.listener.proxy_protocol, envoy.filters.listener.tls_inspector, envoy.listener.http_inspector, envoy.listener.original_dst, envoy.listener.original_src, envoy.listener.proxy_protocol, envoy.listener.tls_inspector
[2021-12-08 20:47:28.513][177845][info][main] [source/server/server.cc:385]   envoy.matching.input_matchers: envoy.matching.matchers.consistent_hashing, envoy.matching.matchers.ip
[2021-12-08 20:47:28.513][177845][info][main] [source/server/server.cc:385]   envoy.retry_host_predicates: envoy.retry_host_predicates.omit_canary_hosts, envoy.retry_host_predicates.omit_host_metadata, envoy.retry_host_predicates.previous_hosts
[2021-12-08 20:47:28.513][177845][info][main] [source/server/server.cc:385]   envoy.tracers: envoy.dynamic.ot, envoy.lightstep, envoy.tracers.datadog, envoy.tracers.dynamic_ot, envoy.tracers.lightstep, envoy.tracers.opencensus, envoy.tracers.skywalking, envoy.tracers.xray, envoy.tracers.zipkin, envoy.zipkin
[2021-12-08 20:47:28.513][177845][info][main] [source/server/server.cc:385]   envoy.http.cache: envoy.extensions.http.cache.simple
[2021-12-08 20:47:28.513][177845][info][main] [source/server/server.cc:385]   envoy.http.original_ip_detection: envoy.http.original_ip_detection.custom_header, envoy.http.original_ip_detection.xff
[2021-12-08 20:47:28.513][177845][info][main] [source/server/server.cc:385]   envoy.filters.udp_listener: envoy.filters.udp.dns_filter, envoy.filters.udp_listener.udp_proxy
[2021-12-08 20:47:28.513][177845][info][main] [source/server/server.cc:385]   envoy.stats_sinks: envoy.dog_statsd, envoy.graphite_statsd, envoy.metrics_service, envoy.stat_sinks.dog_statsd, envoy.stat_sinks.graphite_statsd, envoy.stat_sinks.hystrix, envoy.stat_sinks.metrics_service, envoy.stat_sinks.statsd, envoy.stat_sinks.wasm, envoy.statsd
[2021-12-08 20:47:28.513][177845][info][main] [source/server/server.cc:385]   envoy.resolvers: envoy.ip
[2021-12-08 20:47:28.513][177845][info][main] [source/server/server.cc:385]   envoy.matching.http.input: request-headers, request-trailers, response-headers, response-trailers
[2021-12-08 20:47:28.513][177845][info][main] [source/server/server.cc:385]   envoy.common.key_value: envoy.key_value.file_based
[2021-12-08 20:47:28.513][177845][info][main] [source/server/server.cc:385]   envoy.network.dns_resolver: envoy.network.dns_resolver.apple, envoy.network.dns_resolver.cares
[2021-12-08 20:47:28.514][177845][info][main] [source/server/server.cc:385]   envoy.quic.server.crypto_stream: envoy.quic.crypto_stream.server.quiche
[2021-12-08 20:47:28.514][177845][info][main] [source/server/server.cc:385]   envoy.matching.common_inputs: envoy.matching.common_inputs.environment_variable
[2021-12-08 20:47:28.514][177845][info][main] [source/server/server.cc:385]   envoy.tls.cert_validator: envoy.tls.cert_validator.default, envoy.tls.cert_validator.spiffe
[2021-12-08 20:47:28.514][177845][info][main] [source/server/server.cc:385]   envoy.guarddog_actions: envoy.watchdog.abort_action, envoy.watchdog.profile_action
[2021-12-08 20:47:28.514][177845][info][main] [source/server/server.cc:385]   envoy.transport_sockets.upstream: envoy.transport_sockets.alts, envoy.transport_sockets.quic, envoy.transport_sockets.raw_buffer, envoy.transport_sockets.starttls, envoy.transport_sockets.tap, envoy.transport_sockets.tcp_stats, envoy.transport_sockets.tls, envoy.transport_sockets.upstream_proxy_protocol, raw_buffer, starttls, tls
[2021-12-08 20:47:28.517][177845][info][main] [source/server/server.cc:385]   envoy.access_logger.extension_filters: envoy.access_loggers.extension_filters.cel
[2021-12-08 20:47:28.517][177845][info][main] [source/server/server.cc:385]   envoy.thrift_proxy.filters: envoy.filters.thrift.header_to_metadata, envoy.filters.thrift.rate_limit, envoy.filters.thrift.router
[2021-12-08 20:47:28.517][177845][info][main] [source/server/server.cc:385]   envoy.dubbo_proxy.filters: envoy.filters.dubbo.router
[2021-12-08 20:47:28.517][177845][info][main] [source/server/server.cc:385]   envoy.upstreams: envoy.filters.connection_pools.tcp.generic
[2021-12-08 20:47:28.517][177845][info][main] [source/server/server.cc:385]   envoy.health_checkers: envoy.health_checkers.redis
[2021-12-08 20:47:28.517][177845][info][main] [source/server/server.cc:385]   envoy.rate_limit_descriptors: envoy.rate_limit_descriptors.expr
[2021-12-08 20:47:28.517][177845][info][main] [source/server/server.cc:385]   envoy.thrift_proxy.transports: auto, framed, header, unframed
[2021-12-08 20:47:28.517][177845][info][main] [source/server/server.cc:385]   envoy.clusters: envoy.cluster.eds, envoy.cluster.logical_dns, envoy.cluster.original_dst, envoy.cluster.static, envoy.cluster.strict_dns, envoy.clusters.aggregate, envoy.clusters.dynamic_forward_proxy, envoy.clusters.redis
[2021-12-08 20:47:28.517][177845][info][main] [source/server/server.cc:385]   envoy.matching.action: composite-action, skip
[2021-12-08 20:47:28.517][177845][info][main] [source/server/server.cc:385]   envoy.internal_redirect_predicates: envoy.internal_redirect_predicates.allow_listed_routes, envoy.internal_redirect_predicates.previous_routes, envoy.internal_redirect_predicates.safe_cross_scheme
[2021-12-08 20:47:28.517][177845][info][main] [source/server/server.cc:385]   envoy.http.stateful_header_formatters: preserve_case
[2021-12-08 20:47:28.518][177845][info][main] [source/server/server.cc:385]   envoy.filters.network: envoy.client_ssl_auth, envoy.echo, envoy.ext_authz, envoy.filters.network.client_ssl_auth, envoy.filters.network.connection_limit, envoy.filters.network.direct_response, envoy.filters.network.dubbo_proxy, envoy.filters.network.echo, envoy.filters.network.ext_authz, envoy.filters.network.http_connection_manager, envoy.filters.network.local_ratelimit, envoy.filters.network.mongo_proxy, envoy.filters.network.ratelimit, envoy.filters.network.rbac, envoy.filters.network.redis_proxy, envoy.filters.network.sni_cluster, envoy.filters.network.sni_dynamic_forward_proxy, envoy.filters.network.tcp_proxy, envoy.filters.network.thrift_proxy, envoy.filters.network.wasm, envoy.filters.network.zookeeper_proxy, envoy.http_connection_manager, envoy.mongo_proxy, envoy.ratelimit, envoy.redis_proxy, envoy.tcp_proxy
[2021-12-08 20:47:28.518][177845][info][main] [source/server/server.cc:385]   envoy.compression.compressor: envoy.compression.brotli.compressor, envoy.compression.gzip.compressor
[2021-12-08 20:47:28.519][177845][info][main] [source/server/server.cc:385]   envoy.dubbo_proxy.serializers: dubbo.hessian2
[2021-12-08 20:47:28.519][177845][info][main] [source/server/server.cc:385]   envoy.thrift_proxy.protocols: auto, binary, binary/non-strict, compact, twitter
[2021-12-08 20:47:28.519][177845][info][main] [source/server/server.cc:385]   envoy.dubbo_proxy.route_matchers: default
[2021-12-08 20:47:28.519][177845][info][main] [source/server/server.cc:385]   envoy.wasm.runtime: envoy.wasm.runtime.null, envoy.wasm.runtime.v8
[2021-12-08 20:47:28.519][177845][info][main] [source/server/server.cc:385]   envoy.quic.proof_source: envoy.quic.proof_source.filter_chain
[2021-12-08 20:47:28.521][177845][info][main] [source/server/server.cc:433] HTTP header map info:
[2021-12-08 20:47:28.521][177845][info][main] [source/server/server.cc:436]   request header map: 640 bytes: :authority,:method,:path,:protocol,:scheme,accept,accept-encoding,access-control-request-method,authentication,authorization,cache-control,cdn-loop,connection,content-encoding,content-length,content-type,expect,grpc-accept-encoding,grpc-timeout,if-match,if-modified-since,if-none-match,if-range,if-unmodified-since,keep-alive,origin,pragma,proxy-connection,referer,te,transfer-encoding,upgrade,user-agent,via,x-client-trace-id,x-envoy-attempt-count,x-envoy-decorator-operation,x-envoy-downstream-service-cluster,x-envoy-downstream-service-node,x-envoy-expected-rq-timeout-ms,x-envoy-external-address,x-envoy-force-trace,x-envoy-hedge-on-per-try-timeout,x-envoy-internal,x-envoy-ip-tags,x-envoy-max-retries,x-envoy-original-path,x-envoy-original-url,x-envoy-retriable-header-names,x-envoy-retriable-status-codes,x-envoy-retry-grpc-on,x-envoy-retry-on,x-envoy-upstream-alt-stat-name,x-envoy-upstream-rq-per-try-timeout-ms,x-envoy-upstream-rq-timeout-alt-response,x-envoy-upstream-rq-timeout-ms,x-envoy-upstream-stream-duration-ms,x-forwarded-client-cert,x-forwarded-for,x-forwarded-host,x-forwarded-proto,x-ot-span-context,x-request-id
[2021-12-08 20:47:28.521][177845][info][main] [source/server/server.cc:436]   request trailer map: 128 bytes:
[2021-12-08 20:47:28.521][177845][info][main] [source/server/server.cc:436]   response header map: 424 bytes: :status,access-control-allow-credentials,access-control-allow-headers,access-control-allow-methods,access-control-allow-origin,access-control-expose-headers,access-control-max-age,age,cache-control,connection,content-encoding,content-length,content-type,date,etag,expires,grpc-message,grpc-status,keep-alive,last-modified,location,proxy-connection,server,transfer-encoding,upgrade,vary,via,x-envoy-attempt-count,x-envoy-decorator-operation,x-envoy-degraded,x-envoy-immediate-health-check-fail,x-envoy-ratelimited,x-envoy-upstream-canary,x-envoy-upstream-healthchecked-cluster,x-envoy-upstream-service-time,x-request-id
[2021-12-08 20:47:28.522][177845][info][main] [source/server/server.cc:436]   response trailer map: 152 bytes: grpc-message,grpc-status
[2021-12-08 20:47:28.523][177845][info][main] [source/server/server.cc:772] runtime: {}
[2021-12-08 20:47:28.523][177845][info][admin] [source/server/admin/admin.cc:134] admin address: 0.0.0.0:49898
[2021-12-08 20:47:28.523][177845][info][config] [source/server/configuration_impl.cc:127] loading tracing configuration
[2021-12-08 20:47:28.523][177845][info][config] [source/server/configuration_impl.cc:87] loading 0 static secret(s)
[2021-12-08 20:47:28.523][177845][info][config] [source/server/configuration_impl.cc:93] loading 1 cluster(s)
[2021-12-08 20:47:28.524][177845][info][config] [source/server/configuration_impl.cc:97] loading 1 listener(s)
[2021-12-08 20:47:28.525][177845][warning][config] [source/server/listener_impl.cc:932] reuse_port was configured for TCP listener 'listener_0' and is being force disabled because Envoy is not running on Linux. See the documentation for more information.
[2021-12-08 20:47:28.525][177845][info][config] [source/server/configuration_impl.cc:109] loading stats configuration
[2021-12-08 20:47:28.526][177845][info][main] [source/server/server.cc:868] starting main dispatch loop
[2021-12-08 20:47:28.638][177845][info][runtime] [source/common/runtime/runtime_impl.cc:448] RTDS has finished initialization
[2021-12-08 20:47:28.638][177845][info][upstream] [source/common/upstream/cluster_manager_impl.cc:207] cm init: all clusters initialized
[2021-12-08 20:47:28.638][177845][info][main] [source/server/server.cc:849] all clusters initialized. initializing init manager
[2021-12-08 20:47:28.638][177845][info][config] [source/server/listener_manager_impl.cc:784] all dependencies initialized. starting workers
[2021-12-08 20:47:28.639][177845][warning][main] [source/server/server.cc:747] there is no configured limit to the number of allowed active connections. Set a limit via the runtime key overload.global_downstream_max_connections
==> curl -s 127.0.0.1:49898/clusters?format=json
Killing child processes...
[2021-12-08 20:47:38.539][177845][warning][main] [source/server/server.cc:807] caught ENVOY_SIGTERM
[2021-12-08 20:47:38.539][177845][info][main] [source/server/server.cc:933] shutting down server instance
[2021-12-08 20:47:38.539][177845][info][main] [source/server/server.cc:873] main dispatch loop exited
[2021-12-08 20:47:38.540][177845][info][main] [source/server/server.cc:925] exiting

I build successfully now. I'm not quite sure what the problem was that caused built failed. I uninstalled anaconda and then it works. I think this issue can be closed.

In general I think we should close this one and encourage folks to file new issues as they pop up

hey folks, is m1 fast at compiling envoy? Do people have a good dev experience with m1?

authors: JCzz Patrick0308 antoniovicente carlocab codefromthecrypt davinci26 ggreenway jpsim keith mattklein123 moderation vinayreddy


text:
TSAN test flake in //test/integration:h1_capture_persistent_fuzz_test

//test/integration:h1_capture_persistent_fuzz_test
 ==================
2022-03-16T14:17:37.7351141Z WARNING: ThreadSanitizer: data race (pid=18)
2022-03-16T14:17:37.7351687Z   Write of size 8 at 0x7b540000cbb8 by main thread:
2022-03-16T14:17:37.7353214Z     #0 testing::internal::UnitTestImpl::set_current_test_info(testing::TestInfo*) /proc/self/cwd/external/com_google_googletest/googletest/src/gtest-internal-inl.h:729:24 (h1_capture_persistent_fuzz_test+0x8dfd524)
2022-03-16T14:17:37.7354444Z     #1 testing::TestInfo::Run() /proc/self/cwd/external/com_google_googletest/googletest/src/gtest.cc:2850:9 (h1_capture_persistent_fuzz_test+0x8de0e79)
2022-03-16T14:17:37.7355482Z     #2 testing::TestSuite::Run() /proc/self/cwd/external/com_google_googletest/googletest/src/gtest.cc:2986:28 (h1_capture_persistent_fuzz_test+0x8de1945)
2022-03-16T14:17:37.7356569Z     #3 testing::internal::UnitTestImpl::RunAllTests() /proc/self/cwd/external/com_google_googletest/googletest/src/gtest.cc:5697:44 (h1_capture_persistent_fuzz_test+0x8df1e7b)
2022-03-16T14:17:37.7358101Z     #4 bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) /proc/self/cwd/external/com_google_googletest/googletest/src/gtest.cc:2580:10 (h1_capture_persistent_fuzz_test+0x8e1ff77)
2022-03-16T14:17:37.7360032Z     #5 bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) /proc/self/cwd/external/com_google_googletest/googletest/src/gtest.cc:2616:14 (h1_capture_persistent_fuzz_test+0x8e006b0)
2022-03-16T14:17:37.7361497Z     #6 testing::UnitTest::Run() /proc/self/cwd/external/com_google_googletest/googletest/src/gtest.cc:5280:10 (h1_capture_persistent_fuzz_test+0x8df1723)
2022-03-16T14:17:37.7362502Z     #7 RUN_ALL_TESTS() /proc/self/cwd/external/com_google_googletest/googletest/include/gtest/gtest.h:2485:46 (h1_capture_persistent_fuzz_test+0x684569a)
2022-03-16T14:17:37.7363339Z     #8 main /proc/self/cwd/test/fuzz/main.cc:97:10 (h1_capture_persistent_fuzz_test+0x683c9a2)
2022-03-16T14:17:37.7363704Z
2022-03-16T14:17:37.7364120Z   Previous read of size 8 at 0x7b540000cbb8 by thread T1:
2022-03-16T14:17:37.7364623Z     [failed to restore the stack]
2022-03-16T14:17:37.7364824Z
2022-03-16T14:17:37.7365283Z   Location is heap block of size 552 at 0x7b540000ca80 allocated by main thread:
2022-03-16T14:17:37.7366398Z     #0 malloc /tmp/llvm/utils/release/final/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:651:5 (h1_capture_persistent_fuzz_test+0x286727b)
2022-03-16T14:17:37.7367663Z     #1 operator new(unsigned long) /tmp/tmp.9oihhy9ANQ/llvm-project-llvmorg-12.0.1/libcxxabi/src/stdlib_new_delete.cpp:30:17 (libc++abi.so.1+0x4ed37)
2022-03-16T14:17:37.7368657Z     #2 testing::UnitTest::UnitTest() /proc/self/cwd/external/com_google_googletest/googletest/src/gtest.cc:5329:11 (h1_capture_persistent_fuzz_test+0x8df25ff)
2022-03-16T14:17:37.7369868Z     #3 testing::UnitTest::GetInstance() /proc/self/cwd/external/com_google_googletest/googletest/src/gtest.cc:4974:19 (h1_capture_persistent_fuzz_test+0x8dd1280)
2022-03-16T14:17:37.7370991Z     #4 Envoy::(anonymous namespace)::FuzzerCorpusTest_RunOneCorpusFile_Test::AddToRegistry() /proc/self/cwd/test/fuzz/main.cc:46:1 (h1_capture_persistent_fuzz_test+0x683b728)
2022-03-16T14:17:37.7371989Z     #5 __cxx_global_var_init.2 /proc/self/cwd/test/fuzz/main.cc:46:1 (h1_capture_persistent_fuzz_test+0x6844d65)
2022-03-16T14:17:37.7372796Z     #6 _GLOBAL__sub_I_main.cc /proc/self/cwd/test/fuzz/main.cc (h1_capture_persistent_fuzz_test+0x6844f79)
2022-03-16T14:17:37.7373519Z     #7 __libc_csu_init <null> (h1_capture_persistent_fuzz_test+0x8e7ad7c)
2022-03-16T14:17:37.7373875Z
2022-03-16T14:17:37.7374338Z   Thread T1 (tid=25, running) created by main thread at:
2022-03-16T14:17:37.7375473Z     #0 pthread_create /tmp/llvm/utils/release/final/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:965:3 (h1_capture_persistent_fuzz_test+0x2868aab)
2022-03-16T14:17:37.7376771Z     #1 Envoy::Thread::ThreadImplPosix::ThreadImplPosix(std::__1::function<void ()>, absl::optional<Envoy::Thread::Options> const&) /proc/self/cwd/source/common/common/posix/thread_impl.cc:46:20 (h1_capture_persistent_fuzz_test+0x766485d)
2022-03-16T14:17:37.7378742Z     #2 std::__1::__unique_if<Envoy::Thread::ThreadImplPosix>::__unique_single std::__1::make_unique<Envoy::Thread::ThreadImplPosix, std::__1::function<void ()>&, absl::optional<Envoy::Thread::Options> const&>(std::__1::function<void ()>&, absl::optional<Envoy::Thread::Options> const&) /opt/llvm/bin/../include/c++/v1/memory:2094:32 (h1_capture_persistent_fuzz_test+0x7663e9f)
2022-03-16T14:17:37.7452866Z     #3 Envoy::Thread::ThreadFactoryImplPosix::createThread(std::__1::function<void ()>, absl::optional<Envoy::Thread::Options> const&) /proc/self/cwd/source/common/common/posix/thread_impl.cc:121:10 (h1_capture_persistent_fuzz_test+0x7663c0d)
2022-03-16T14:17:37.7455032Z     #4 Envoy::FakeUpstream::FakeUpstream(std::__1::unique_ptr<Envoy::Network::TransportSocketFactory, std::__1::default_delete<Envoy::Network::TransportSocketFactory> >&&, std::__1::unique_ptr<Envoy::Network::Socket, std::__1::default_delete<Envoy::Network::Socket> >&&, Envoy::FakeUpstreamConfig const&) /proc/self/cwd/test/integration/fake_upstream.cc:580:35 (h1_capture_persistent_fuzz_test+0x2c8627e)
2022-03-16T14:17:37.7458290Z     #5 Envoy::FakeUpstream::FakeUpstream(std::__1::unique_ptr<Envoy::Network::TransportSocketFactory, std::__1::default_delete<Envoy::Network::TransportSocketFactory> >&&, std::__1::shared_ptr<Envoy::Network::Address::Instance const> const&, Envoy::FakeUpstreamConfig const&) /proc/self/cwd/test/integration/fake_upstream.cc:550:7 (h1_capture_persistent_fuzz_test+0x2c86856)
2022-03-16T14:17:37.7460251Z     #6 Envoy::BaseIntegrationTest::createUpstreams() /proc/self/cwd/test/integration/base_integration_test.cc:155:15 (h1_capture_persistent_fuzz_test+0x2b80c68)
2022-03-16T14:17:37.7461458Z     #7 Envoy::BaseIntegrationTest::initialize() /proc/self/cwd/test/integration/base_integration_test.cc:100:3 (h1_capture_persistent_fuzz_test+0x2b7fb33)
2022-03-16T14:17:37.7462602Z     #8 Envoy::HttpIntegrationTest::initialize() /proc/self/cwd/test/integration/http_integration.cc:343:33 (h1_capture_persistent_fuzz_test+0x29afa5c)
2022-03-16T14:17:37.7463773Z     #9 Envoy::H1FuzzIntegrationTest::initialize() /proc/self/cwd/test/integration/h1_capture_fuzz_test.cc:4:65 (h1_capture_persistent_fuzz_test+0x28d8915)
2022-03-16T14:17:37.7464989Z     #10 Envoy::H1FuzzIntegrationTest::replay(test::integration::CaptureFuzzTestCase const&, bool)::$_0::operator()() const /proc/self/cwd/test/integration/h1_fuzz.cc:16:5 (h1_capture_persistent_fuzz_test+0x2986776)
2022-03-16T14:17:37.7466317Z     #11 Envoy::H1FuzzIntegrationTest::replay(test::integration::CaptureFuzzTestCase const&, bool) /proc/self/cwd/test/integration/h1_fuzz.cc:15:42 (h1_capture_persistent_fuzz_test+0x29841bf)
2022-03-16T14:17:37.7467552Z     #12 Envoy::TestOneProtoInput(test::integration::CaptureFuzzTestCase const&) /proc/self/cwd/test/integration/h1_capture_fuzz_test.cc:11:28 (h1_capture_persistent_fuzz_test+0x28d92ca)
2022-03-16T14:17:37.7468519Z     #13 LLVMFuzzerTestOneInput /proc/self/cwd/test/integration/h1_capture_fuzz_test.cc:6:1 (h1_capture_persistent_fuzz_test+0x28d8c7f)
2022-03-16T14:17:37.7469442Z     #14 Envoy::(anonymous namespace)::FuzzerCorpusTest_RunOneCorpusFile_Test::TestBody() /proc/self/cwd/test/fuzz/main.cc:50:3 (h1_capture_persistent_fuzz_test+0x6840689)
2022-03-16T14:17:37.7470668Z     #15 void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) /proc/self/cwd/external/com_google_googletest/googletest/src/gtest.cc:2580:10 (h1_capture_persistent_fuzz_test+0x8e19877)
2022-03-16T14:17:37.7472437Z     #16 void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) /proc/self/cwd/external/com_google_googletest/googletest/src/gtest.cc:2616:14 (h1_capture_persistent_fuzz_test+0x8dfce30)
2022-03-16T14:17:37.7473778Z     #17 testing::Test::Run() /proc/self/cwd/external/com_google_googletest/googletest/src/gtest.cc:2655:5 (h1_capture_persistent_fuzz_test+0x8ddfec7)
2022-03-16T14:17:37.7474906Z     #18 testing::TestInfo::Run() /proc/self/cwd/external/com_google_googletest/googletest/src/gtest.cc:2832:11 (h1_capture_persistent_fuzz_test+0x8de0d7a)
2022-03-16T14:17:37.7475969Z     #19 testing::TestSuite::Run() /proc/self/cwd/external/com_google_googletest/googletest/src/gtest.cc:2986:28 (h1_capture_persistent_fuzz_test+0x8de1945)
2022-03-16T14:17:37.7477067Z     #20 testing::internal::UnitTestImpl::RunAllTests() /proc/self/cwd/external/com_google_googletest/googletest/src/gtest.cc:5697:44 (h1_capture_persistent_fuzz_test+0x8df1e7b)
2022-03-16T14:17:37.7478642Z     #21 bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) /proc/self/cwd/external/com_google_googletest/googletest/src/gtest.cc:2580:10 (h1_capture_persistent_fuzz_test+0x8e1ff77)
2022-03-16T14:17:37.7480574Z     #22 bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) /proc/self/cwd/external/com_google_googletest/googletest/src/gtest.cc:2616:14 (h1_capture_persistent_fuzz_test+0x8e006b0)
2022-03-16T14:17:37.7482046Z     #23 testing::UnitTest::Run() /proc/self/cwd/external/com_google_googletest/googletest/src/gtest.cc:5280:10 (h1_capture_persistent_fuzz_test+0x8df1723)
2022-03-16T14:17:37.7483089Z     #24 RUN_ALL_TESTS() /proc/self/cwd/external/com_google_googletest/googletest/include/gtest/gtest.h:2485:46 (h1_capture_persistent_fuzz_test+0x684569a)
2022-03-16T14:17:37.7483986Z     #25 main /proc/self/cwd/test/fuzz/main.cc:97:10 (h1_capture_persistent_fuzz_test+0x683c9a2)
2022-03-16T14:17:37.7484401Z
2022-03-16T14:17:37.7485927Z SUMMARY: ThreadSanitizer: data race /proc/self/cwd/external/com_google_googletest/googletest/src/gtest-internal-inl.h:729:24 in testing::internal::UnitTestImpl::set_current_test_info(testing::TestIn

@adisuissa can you assign this to whoever you think should own fuzz bugs nowadays?

https://dev.azure.com/cncf/4684fb3d-0389-4e0b-8251-221942316e06/_apis/build/builds/107022/logs/270

+1 to disabling flaky tests.

source: gharchive/issue

authors: alyssawilk ggreenway jmarantz

repo: envoyproxy/envoy

license_type: permissive

license_source: github-api


text:
delta-xDS doesn't update the known resource version for wildcard resources

Title: delta-xDS doesn't update the known resource version for wildcard resources
Description:
The current implementation of the delta-xDS for wildcard responses only stores the initial version for a resource name that Envoy observes, instead of the version of the latest update.
See here:
https://github.com/envoyproxy/envoy/blob/04aae9f17b0223013cff7285539b5ee2485c5bc1/source/common/config/new_delta_subscription_state.cc#L378
and here:
https://github.com/envoyproxy/envoy/blob/04aae9f17b0223013cff7285539b5ee2485c5bc1/source/common/config/new_delta_subscription_state.cc#L81
This can lead to using a stale resource without the server knowing about it.
For example:

Envoy receives resource_A v1 from server (updates the map to v1).
Envoy receives resource_A v2 from server (doesn't update the map, because it already has a resource with the same name).
Envoy reconnects to a new server (that only knows about v1), and publishes it has v1, although the actual resource is of v2. -> The server won't send Envoy an update until that resource is updated on the server.

Using insert_or_assign should solve the issue.

/cc stevenzzzz

authors: adisuissa stevenzzzz


text:
One second delay in gRPC load balancing - is it an Envoy or gRPC issue?

Title: One second delay in gRPC load balancing
Description:
We are using Envoy proxy v1.17.0 as a sidecar container in a Kubernetes service to achieve gRPC load balancing to a backend service.
We launch 3 gRPC operations in parallel on the gRPC channel from 3 C++ threads. Setup and operation sketch:

Used Envoy configuration:
    static_resources:
      listeners:
      - address:
          socket_address:
            address: 0.0.0.0
            port_value: 10000
        filter_chains:
        - filters:
          - name: envoy.http_connection_manager
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
              codec_type: auto
              stat_prefix: ingress_http
              route_config:
                name: local_route
                virtual_hosts:
                - name: backend
                  domains:
                  - "*"
                  routes:
                  - match:
                      prefix: "/backend_service_namespace.BackendService/"
                      headers:
                      - name: content-type
                        exact_match: application/grpc
                    route:
                      cluster: our-backend-service
              http_filters:
              - name: envoy.filters.http.router
      clusters:
      - name: our-backend-service
        connect_timeout: 0.5s
        type: strict_dns
        lb_policy: round_robin
        http2_protocol_options: {}
        load_assignment:
          cluster_name: our-backend-service
          endpoints:
          - lb_endpoints:
            - endpoint:
                address:
                  socket_address:
                    address: backend-service-headless
                    port_value: 8181

Experienced behavior:
We experience a 1-second delay quite often (~30-50% of cases) in case of one of the three operations. In these cases, the backend service gets the gRPC request only after 1 second. (Note: all operations are served in microseconds in the backends, so the other gRPC requests are not using the channels for anywhere near 1 second.)
Investigation:
Envoy logs (-l trace) show no errors apart from these:
[2022-07-29 06:49:29.417][14][trace][connection] [source/common/network/raw_buffer_socket.cc:39] [C54] read error: Resource temporarily unavailable

This seems to be OK, however, as it appears quite often in the logs, even where there is no 1-sec delay.
gRPC logs show errors connecting to Envoy (localhost:10000) after a 1-sec gap from the previous log-entry:
I0801 21:45:23.281823311     780 chttp2_transport.cc:2601]   ipv4:10.255.73.68:53394: Complete BDP ping err="OK"
I0801 21:45:24.277774547     104 subchannel.cc:913]          subchannel 0x7efc7c849c00 {address=ipv6:[::1]:10000, args=grpc.client_channel_factory=0x7efd53808028, grpc.default_authority=localhost:10000, grpc.internal.channel_credentials=0x7efc7c81a4a0, grpc.internal.security_connector=0x7efc7c886800, grpc.internal.subchannel_pool=0x7efc7c812750, grpc.primary_user_agent=grpc-c++/1.45.2, grpc.resource_quota=0x7efcb573d150, grpc.server_uri=dns:///localhost:10000}: failed to connect to channel, retrying

Same behavior with v1.22 and v1.23 versions.
Questions:

Is it likely an Envoy or gRPC issue?
It seems that gRPC issues the 1-sec delay for some reason, but its cause is unclear in the abscence of the gRPC load balancing implementation details in Envoy. (How is gRPC used from within Envoy, with what settings, is the connection error between the service and Envoy, or between Envoy and the backends, etc.)
Do we have any debug options in Envoy that are worth trying to dig deeper into the issue?
Do we have any configuration options in Envoy that we can experiece with in order to fine-tune the underlying gRPC load balancing?

Any clue is appreciated, thanks in advance!

I0801 21:45:24.277774547     104 subchannel.cc:913]          subchannel 0x7efc7c849c00 {address=ipv6:[::1]:10000, args=grpc.client_channel_factory=0x7efd53808028, grpc.default_authority=localhost:10000, grpc.internal.channel_credentials=0x7efc7c81a4a0, grpc.internal.security_connector=0x7efc7c886800, grpc.internal.subchannel_pool=0x7efc7c812750, grpc.primary_user_agent=grpc-c++/1.45.2, grpc.resource_quota=0x7efcb573d150, grpc.server_uri=dns:///localhost:10000}: failed to connect to channel, retrying

From this line it seems your gRPC client is trying to connect to IPv6 localhost ::1 first, while Envoy only listens to IPv4, that fallback retry could be the reason of the delay. What if you use 127.0.0.1 instead of localhost?

It does seem to solve the issue! I've tried to send a good bunch of requests and none of them produced the 1-sec delay in any of the gRPC operations.
What is unclear to me, though, is that if we always attempt to connect to IPv6 localhost first, causing a delay, how can some requests be fast (ie. all 3 associated gRPC calls are served by the backends quickly), and only some slow (ie. some of the 3 gRPC calls experience the delay). Naively I would assume that all requests should be served the same way, either slowly or fast.

Usually the IPv6 to v4 fallback is cached in some sense, so subsequent connection won't experience delay, also the gRPC connection can serve multiple requests so the delay is only happens on the first request for that connection.
Going to close this as it doesn't seem to be an Envoy issue.

OK, thanks for the help and the background info.

authors: lenardpi lizan


text:
Dont run (mobile) github actions (for required checks) if there is no need

In #24407 a change was made to not use the paths feature in github actions to exclude checks
this was done to ensure that the checks could be required for PRs to pass
the problem with this approach is that it pulls a full copy of the repo and is much slower than using githubs paths (which afaict uses its own diff algorithm against the target branch, and perhaps pre-checksout the repo - not sure about this exactly)
in more recent version of the github actions/checkout action the default is to pull the repo with a depth of 1, so the current mobile/should_run_ci.sh script, where it assumes that the full repo is checked out, breaks (this is easy enough to workaround but just hightlights the issue)
i think we can speed this up and reduce the load on CI considerably by reverting to using the paths selector and adding the github way of allowing a required check to pass when skipped (https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks#handling-skipped-but-required-checks)
like the azp way its a bit kludgy but it think it would be quite a bit faster/more efficient

cc @jpsim @alyssawilk
i was going to comment something similar on the PR but it landed before i had gotten round to reviewing it

i think we can speed this up and reduce the load on CI considerably by reverting to using the paths selector and adding the github way of allowing a required check to pass when skipped (https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks#handling-skipped-but-required-checks)

Oh nice, I wasn't aware that this was possible.

authors: jpsim phlax


text:
//test/extensions/filters/http/tap:tap_filter_integration_test is flakey

This test has been flakey for a long time, albeit infrequently
It affects release branches also - seemingly more often which may indicate some caching issue
An example CI failure:

AIL: //test/extensions/filters/http/tap:tap_filter_integration_test (see /build/tmp/_bazel_envoybuild/b570b5ccd0454dc9af9f65ab1833764d/execroot/envoy/bazel-out/aarch64-opt/testlogs/test/extensions/filters/http/tap/tap_filter_integration_test/test_attempts/attempt_1.log)

FLAKY: //test/extensions/filters/http/tap:tap_filter_integration_test (Summary)
      /build/tmp/_bazel_envoybuild/b570b5ccd0454dc9af9f65ab1833764d/execroot/envoy/bazel-out/aarch64-opt/testlogs/test/extensions/filters/http/tap/tap_filter_integration_test/test_attempts/attempt_1.log
INFO: From Testing //test/extensions/filters/http/tap:tap_filter_integration_test:
==================== Test output for //test/extensions/filters/http/tap:tap_filter_integration_test:
[==========] Running 40 tests from 1 test suite.
[----------] Global test environment set-up.
[----------] 40 tests from IpVersions/TapIntegrationTest
[ RUN      ] IpVersions/TapIntegrationTest.StaticFilePerTap/IPv4
[external/com_google_absl/absl/flags/internal/flag.cc : 115] RAW: Restore saved value of envoy_reloadable_features_no_extension_lookup_by_name to: true
[external/com_google_absl/absl/flags/internal/flag.cc : 115] RAW: Restore saved value of envoy_reloadable_features_runtime_initialized to: false
[       OK ] IpVersions/TapIntegrationTest.StaticFilePerTap/IPv4 (82 ms)
[ RUN      ] IpVersions/TapIntegrationTest.StaticFilePerTap/IPv6
[external/com_google_absl/absl/flags/internal/flag.cc : 115] RAW: Restore saved value of envoy_reloadable_features_no_extension_lookup_by_name to: true
[external/com_google_absl/absl/flags/internal/flag.cc : 115] RAW: Restore saved value of envoy_reloadable_features_runtime_initialized to: false
[       OK ] IpVersions/TapIntegrationTest.StaticFilePerTap/IPv6 (60 ms)
[ RUN      ] IpVersions/TapIntegrationTest.StaticFilePerTapWithMatchConfigAndMatch/IPv4
[external/com_google_absl/absl/flags/internal/flag.cc : 115] RAW: Restore saved value of envoy_reloadable_features_no_extension_lookup_by_name to: true
[external/com_google_absl/absl/flags/internal/flag.cc : 115] RAW: Restore saved value of envoy_reloadable_features_runtime_initialized to: false
[       OK ] IpVersions/TapIntegrationTest.StaticFilePerTapWithMatchConfigAndMatch/IPv4 (67 ms)
[ RUN      ] IpVersions/TapIntegrationTest.StaticFilePerTapWithMatchConfigAndMatch/IPv6
[external/com_google_absl/absl/flags/internal/flag.cc : 115] RAW: Restore saved value of envoy_reloadable_features_no_extension_lookup_by_name to: true
[external/com_google_absl/absl/flags/internal/flag.cc : 115] RAW: Restore saved value of envoy_reloadable_features_runtime_initialized to: false
[       OK ] IpVersions/TapIntegrationTest.StaticFilePerTapWithMatchConfigAndMatch/IPv6 (48 ms)
[ RUN      ] IpVersions/TapIntegrationTest.StaticFilePerTapWithMatchConfig/IPv4
[external/com_google_absl/absl/flags/internal/flag.cc : 115] RAW: Restore saved value of envoy_reloadable_features_no_extension_lookup_by_name to: true
[external/com_google_absl/absl/flags/internal/flag.cc : 115] RAW: Restore saved value of envoy_reloadable_features_runtime_initialized to: false
[       OK ] IpVersions/TapIntegrationTest.StaticFilePerTapWithMatchConfig/IPv4 (47 ms)
[ RUN      ] IpVersions/TapIntegrationTest.StaticFilePerTapWithMatchConfig/IPv6
[2023-02-20 09:25:53.441][16470][critical][backtrace] [./source/server/backtrace.h:96] #10: Envoy::TestRunner::RunTests() [0x151db58]
[2023-02-20 09:25:53.451][16470][critical][backtrace] [./source/server/backtrace.h:96] #11: main [0x151c900]
[2023-02-20 09:25:53.451][16470][critical][backtrace] [./source/server/backtrace.h:96] #12: __libc_start_main [0xffffa26bbe10]
================================================================================

https://dev.azure.com/cncf/envoy/_build/results?buildId=128658&view=logs&j=767be981-567e-57d8-68c3-2140ede0a0bd&t=1fb0b72f-6293-562d-a4d1-bb649223eaca&l=567
not sure if this is related to #13132
i havent been able to repro locally

cc @daixiang0 @mattklein123

/cc @xu1zhou

... I can not see any info in ...

seems that log has disappeared
i see it reasonably often so i will post next time i do

ive seen this again on the 1.22 branch but not by itself anywhere else, other than as part of failing tsan tests (#25760 )

here is an example on the 1.25 branch https://dev.azure.com/cncf/envoy/_build/results?buildId=129440&view=logs&j=767be981-567e-57d8-68c3-2140ede0a0bd&t=1fb0b72f-6293-562d-a4d1-bb649223eaca&l=3614
hopefully it will be retained
i have been seeing similar with local (tsan) testing - i guess due to not using RBE (#25760) - i need to figure out better why this is happening


text:
Full text for RESPONSE_FLAGS in access logs

The %RESPONSE_FLAGS% access log flag will output additional information in values which may not be understood (most of them) unless referring to the docs. This feature request is for additional flag %RESPONSE_FLAGS_FULL% that would support the same flags, but will full text description in pascal case. For example, UH would map to UnhealthyUpstream.

Sure sounds good.


text:
add support of owned string in the FieldType of ObjectReflection

Title: add support of owned string in the FieldType of ObjectReflection
Description:
Now the FieldType only support string view and number. It's impossible to return a string that has independent lifetime.
[optional Relevant Links:]

Any extra documentation required to understand the issue.

Maybe the InlineString is a possible solution for this requirement.
cc @kyessenov

TLVs are stored as inlined character arrays, we could use string views, no? If we don't keep the field values trivial, we would have to provide more memory management, and possible bugs with it.

authors: kyessenov wbpcode


text:
Add an new tap sink

Title: Enhancement to add a new tap sink
Description:

current tap sinks:

File_per_tap, the performance is very low
Streaming/buffered_Admin, it will block main thread routine work. Also the performance is low.
Custom_sink,issue link until now, I don’t know how to use it based current investigation :(

Based above reason, I want to add a nice performance “UDP” sink.
As why this sink is needed, as you know, all upstream traffic is passed by TLS. Especially, TLS1.3, it can’t get original data even with tcpdump tool.
[optional Relevant Links:]

Any extra documentation required to understand the issue.

wait for contribution! ^_^
Thanks,
zhmzhen

[!NOTE]
Below is only private code for unix socket sink( not UT code). paste here for reference

1) configuration changes
--- a/api/envoy/config/tap/v3/common.proto
+++ b/api/envoy/config/tap/v3/common.proto
@@ -2,6 +2,7 @@ syntax = "proto3";
 package envoy.config.tap.v3;
+import "envoy/config/core/v3/address.proto";
 import "envoy/config/common/matcher/v3/matcher.proto";
 import "envoy/config/core/v3/base.proto";
 import "envoy/config/core/v3/extension.proto";
@@ -263,6 +264,11 @@ message OutputSink {

     // Tap output filter will be defined by an extension type
     core.v3.TypedExtensionConfig custom_sink = 6;
+
+    // US output sink
+    UnixSocketSink us_sink = 8;
   }
 }

+//  The Unix socket sink for fast sinking
+message UnixSocketSink {
+  string su_path = 1 [(validate.rules).string = {min_len: 1}];
+}

2) Real code
2.1)
--- a/source/extensions/common/tap/tap_config_base.h
+++ b/source/extensions/common/tap/tap_config_base.h
+// UNIX socket sink definition
+class USTapSink : public Sink {
+public:
+  USTapSink(const envoy::config::tap::v3::UnixSocketSink& config) : config_(config) {
+    initUSData();
+  }
+  ~USTapSink() {
+    if (socket_fd_ > 0) {
+      close(socket_fd_);
+      socket_fd_ = -1;
+    }
+  }
+
+  // Sink
+  PerTapSinkHandlePtr
+  createPerTapSinkHandle(uint64_t trace_id,
+                         envoy::config::tap::v3::OutputSink::OutputSinkTypeCase) override {
+    return std::make_unique<USTapSinkHandle>(*this, trace_id);
+  }
+  void initUSData(void);
+
+private:
+  struct USTapSinkHandle : public PerTapSinkHandle {
+    USTapSinkHandle(USTapSink& parent, uint64_t trace_id)
+        : parent_(parent), trace_id_(trace_id) {}
+
+    // PerTapSinkHandle
+    void submitTrace(TraceWrapperPtr&& trace,
+                     envoy::config::tap::v3::OutputSink::Format format) override;
+
+    USTapSink& parent_;
+    const uint64_t trace_id_;
+  };
+
+  const envoy::config::tap::v3::UnixSocketSink config_;
+  int socket_fd_ = -1;
+  struct sockaddr_un server_addr_;
+};ore--
+// The end of Unix Socket sink
+

2.2) implementation
-- a/source/extensions/common/tap/tap_config_base.cc
+++ b/source/extensions/common/tap/tap_config_base.cc
@@ -8,6 +8,7 @@
 #include "source/common/common/assert.h"
 #include "source/common/common/fmt.h"
 #include "source/common/config/utility.h"
+#include "source/common/network/utility.h"
 #include "source/common/protobuf/utility.h"
 #include "source/extensions/common/matcher/matcher.h"

@@ -98,6 +99,20 @@ TapConfigBaseImpl::TapConfigBaseImpl(const envoy::config::tap::v3::TapConfig& pr
     sink_ = std::make_unique<FilePerTapSink>(sinks[0].file_per_tap());
     sink_to_use_ = sink_.get();
     break;
+  case ProtoOutputSink::OutputSinkTypeCase::kUsSink:
+    {
+    sink_ = std::make_unique<USTapSink>(sinks[0].us_sink());
+    sink_to_use_ = sink_.get();
+    ENVOY_LOG_MISC(debug, "CFXUS, Done init data");
+    }
+    break;
   case ProtoOutputSink::OutputSinkTypeCase::kCustomSink: {

+void USTapSink::initUSData(void) {
+   ENVOY_LOG_MISC(debug, "CFXUS, USTapSink::initUSData, enter");
+
+   if ((socket_fd_ = socket(AF_UNIX, SOCK_STREAM, 0)) < 0) {
+     ENVOY_LOG_MISC(debug, "CFXUS, USTapSink::initUDPData failed to create US socket\n");
+     return;
+   }
+   server_addr_.sun_family = AF_UNIX;
+   strcpy(server_addr_.sun_path, config_.su_path().c_str());
+   int len = sizeof(server_addr_.sun_family) + strlen(server_addr_.sun_path);
+   if (connect(socket_fd_, reinterpret_cast<struct sockaddr *>(&server_addr_), len) < 0) {
+     ENVOY_LOG_MISC(debug, "CFXU, USTapSink::initUSData Connect to server, su_path={}", config_.su_path().c_str());
+     close(socket_fd_);
+     socket_fd_ = -1;
+     return;
+   }
+
+   ENVOY_LOG_MISC(debug, "CFXUS, exit USTapSink::initUSData, sokcet_fd={}, su_path={}",
+                   socket_fd_,  config_.su_path().c_str());
+}
+
+void USTapSink::USTapSinkHandle::submitTrace(
+    TraceWrapperPtr&& trace, envoy::config::tap::v3::OutputSink::Format format) {
+  ENVOY_LOG_MISC(debug, "CFXUS, UsTapSink::UsTapSinkHandle::submitTrace, enter [id={}] ", trace_id_);
+  switch (format) {
+    PANIC_ON_PROTO_ENUM_SENTINEL_VALUES;
+  case envoy::config::tap::v3::OutputSink::PROTO_BINARY:
+  case envoy::config::tap::v3::OutputSink::PROTO_BINARY_LENGTH_DELIMITED:
+  case envoy::config::tap::v3::OutputSink::PROTO_TEXT:
+    ENVOY_LOG_MISC(debug, "CFXUS, Notsupport PROTO_BINARY, PROTO_BINARY_LENGTH_DELIMITED,  PROTO_TEXT\n");
+    break;
+  case envoy::config::tap::v3::OutputSink::JSON_BODY_AS_BYTES:
+  case envoy::config::tap::v3::OutputSink::JSON_BODY_AS_STRING:
+    {
+      std::string json_string =  MessageUtil::getJsonStringFromMessageOrError(*trace, true, true);
+      ENVOY_LOG_MISC(debug, "CFXU, message is <\n{}\n", json_string);
+      if (parent_.socket_fd_ < 0) {
+        ENVOY_LOG_MISC(debug, "CFXU, parent_.socket_fd_ < 0 {}\n", parent_.socket_fd_);
+      } else {
+        int l_str_len = json_string.size();
+        int l_w_len = write(parent_.socket_fd_, json_string.c_str(), l_str_len);
+        int l_w_total_len = 0;
+        int l_con_len = 0;
+        while ( 1 )
+        {
+          if (l_w_len <= 0) {
+           if (errno == EINTR || errno == EAGAIN || errno == EWOULDBLOCK) {
+              if (l_con_len++ >= 3) {
+                ENVOY_LOG_MISC(debug, "CFXUS, Failed to write US after 3 times\n");
+                break;
+              }
+             continue;
+            }
+            // other errors
+            ENVOY_LOG_MISC(debug, "CFXUS, other Failure to write US\n");
+            break;
+          } else {
+            l_w_total_len = l_w_total_len + l_w_len;
+            if (l_w_total_len == l_str_len) {
+               // write done
+               ENVOY_LOG_MISC(debug, "CFXUS, write US size {}\n", l_w_total_len);
+               break;
+            } else {
+               l_w_len = write(parent_.socket_fd_,
+                               json_string.c_str() + l_w_total_len, l_str_len - l_w_total_len);
+            }
+          }
+       }
+     }
+   }
+   break;
+  }
+  ENVOY_LOG_MISC(debug, "CFXUS, USTapSink::USTapSinkHandle::submitTrace: End");
+  return;
+}

 } // namespace Tap
 } // namespace Common

below is the full configuration file for unixsocket
unixSocketSink.yaml.txt

[!IMPORTANT]
When using above file, please remove .txt

cc @mattklein123 @xu1zhou

Please let me know if anyone want to try private code changes.
thanks
Cliff

Changing UDP sink code ......

PR is wait for review

change to add UDP extension sink for tap custom sink

authors: coolg92003 nezdolik zhmzhen


text:
[fuzz] Added fuzzer for HttpHealthCheckerImpl

Signed-off-by: Zach Reyes zasweq@google.com
Commit Message: Added fuzzer for HttpHealthCheckerImpl.
Additional Description: Logical ASSERTS will come later in a separate class if needed.
Risk Level: Low
Testing: N/A
Docs Changes: N/A
Release Notes: N/A

/assign @asraa @htuch @adisuissa

Is there anyway we can review this one first and keep TCP for the second PR? Just for keeping comment history on a single PR.

Is there anyway we can review this one first and keep TCP for the second PR? Just for keeping comment history on a single PR.

+1. It is generally considered a good practice to create a series of small PRs that gradually provide more features.

Yeah sounds good! Let me switch back to this branch.

Note: Added support for raise events in this commit. Was previously not there/looked at.

source: gharchive/pull-request

authors: adisuissa asraa zasweq


text:
route.proto: add is_optional field to ClusterSpecifierPlugin

Signed-off-by: Doug Fawley dfawley@google.com
Commit Message: route.proto: add is_optional field to ClusterSpecifierPlugin
Additional Description:
When deploying a new cluster specifier plugin, it is often necessary to add it to the configuration before all clients can be updated to support it, with routing rules configured to prevent clients without support from selecting any routes referencing the plugin.  This field will allow those clients to suppress the default behavior of NACKing any resource containing the unknown plugin.
Risk Level: None
Testing: None
Docs Changes: None
Release Notes: None
Platform Specific Features: None
@markdroth @ejona86

This looks great to me.
@lizan, can you please provide a non-Google API review here?  Thanks!

/lgtm api

@dfawley please fix CI.

@ggreenway apologies; I had not noticed the CI failures.  I fixed the formatting, so it should be good to go now.

/lgtm api (based on Lizan's earlier approval, since it's just a formatting change since then)

/lgtm api

@dfawley do you plan to implement this in this PR? If not it should have not-implemented-hide tag.

@lizan The entire ClusterSpecifierPlugin message is already not implemented in Envoy, so this just adds another field to a message that's already not implemented.  There is a not-implemented tag here.  I don't think we need another one for this individual field.

@lizan Any reason not to merge this?  Thanks!

authors: dfawley ggreenway lizan markdroth


text:
Reduce EDS Cluster memory utilization overhead from storing cluster name multiple times

Reduce EDS Cluster memory utilization overhead from storing cluster name multiple times.
This PR improves cluster memory efficiency in 2 ways:

It avoids absl::optional overhead when storing eds name in ClusterInfoImpl -- for non-EDS clusters optional overhead is 8 bytes, even though no eds name is used.
It avoids a copy of the eds cluster name in EdsClusterImpl -- since EdsClusterImpl holds a shared_ptr to ClusterInfoImpl already, and EdsClusterImpl holds the eds service name, EdsClusterImpl can get it from there, instead of keeping a copy.

This is a step towards more memory efficient config data structures. Issue #24154.

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

/assign @yanavlasov

LGTM

/assign @DiazAlan

/assign @adisuissa

/retest

/wait

apologies - ive cancelled CI - please hold off pushing until we have progressed the releases that are currently going through

/retest

/assign-from @envoyproxy/senior-maintainers

authors: phlax stevenzzzz yanavlasov yurykats


text:
deps: Bump com_github_google_libprotobuf_mutator -> 1.3

Fix #31861

Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

external/com_github_google_libprotobuf_mutator/src/field_instance.h:198:21: error: no matching function for call to 'StrCat'
    std::string s = absl::StrCat(*descriptor_);

i think we hit this previously elsewhere - trying to rem the reason

/wait
on CI

authors: RyanTheOptimist phlax


text:
mobile: Make Android HTTP proxy test hermetic

This updates the Android HTTP proxy test hermetic by sending a request to a test proxy server instead of sending a request to api.lyft.com.
Risk Level: low (test only)
Testing: unit test
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: n/a

/assign @abeyad

/retest

/retest


text:
syscalls: minor refactor, adding coverage

minor refactor no longer fast-failing if the system can't create sockets.
Risk Level: low
Testing: added tests, manually tested fd failure
Docs Changes: n/a
Release Notes: n/a

Ready for review, PTAL


text:
Update dependencies, standardize on retrieval via tag where available

Signed-off-by: Michael Payne michael@sooper.org
Dependency: Upgrade to backward-cpp v1.4, grpc v1.14.2, googletest v1.8.1, rules_go 0.11.2, buildifier 0.15.0, nghttp2 1.33.0 and subpar 1.3.0. This PR does not update dependencies that rely on commit shas.
Description: nghttp1 1.33.0 release notes, backward-cpp v1.4 release notes, grpc release notes, rules_go release notes, buildifier release notes, googletest release notes and subpar commits & release notes. Add commit date comments to libprotobuf-mutator & jwt_verify_lib
Risk Level: Low
Testing: bazel test //test/... and running on local instances.
Docs Changes: none required
Release Notes: none required

+1 to having sha256. @htuch We might need to switch to http_archive from git_repository, it doesn't seems the Skylark git_repository has sha256 support. It also benefits CI speed.

Now that Pandora's box has been opened, should also loop in @jmillikin-stripe to make sure we're all in agreement :)

I have a commit that add the sha256 for each of the dependencies. What is the impact of  https://docs.bazel.build/versions/master/be/workspace.html#git_repository.sha256 that says

Specifying this forces the repository to be downloaded as a tarball.

LGTM, thanks!

@zuercher looks like we're missing sha256sum in the CI image for CircleCI, this is why the Mac build fails. Thoughts? I suppose we should add this as a dependency in https://github.com/envoyproxy/envoy/tree/master/bazel#quick-start-bazel-build-for-developers @moderation.

authors: htuch lizan moderation


text:
Implement rm-override

resolves #130
Implementation Open Questions

use one Context for commands Override and RmOverride?
how to handle removing empty patch table? (See comment in Code)

Could you check the failed tests, please? These fail because the existence of the manifest is checked before the package details are built. Is it ok to adopt the output errors in the tests, or does these tests have to be changed?

Could you check the failed tests, please? These fail because the existence of the manifest is checked before the package details are built. Is it ok to adopt the output errors in the tests, or does these tests have to be changed?

@teamplayer3, I'm ver sorry I took a whole week to responded. Last week was particularly busy at work so I didn't get many chances to look at open source. I'll also check out your other PR as soon as I get the chance.
The changes to the output look fine. Feel free to adopt the new output in the tests :+1: . Once that's done, I think I'm happy to merge

In test patch_path_doesnt_exist I have problems filtering the os error. @eopb have you an idea how to write the regex for it? Related to #147 .

I think, as described in https://github.com/eopb/cargo-override/issues/147#issuecomment-2366963291, we can remove snapshots that assert on cargo metadata output. assert.failure() should be enough for these cases where the output is so fragile.

I think, as described in https://github.com/eopb/cargo-override/issues/147#issuecomment-2366963291, we can remove snapshots that assert on cargo metadata output. assert.failure() should be enough for these cases where the output is so fragile.

Maybe there are two points we can learn of these specific tests. First we recognize something like in #155. Secondly, the error could be too complicated and should be simplified and be implemented by cargo-override, maybe.
Yeah, it could be too picky.

repo: eopb/cargo-override


text:
[Feature]:chat DATA,配置的DB-GPT本地服务器的数据库连接就能回答问题，但配置的远程数据库连接，问问题无反应，这是怎么回事？

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like
A clear and concise description of what you want to happen.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like A clear and concise description of what you want to happen.
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
Additional context Add any other context or screenshots about the feature request here.

try to telnet hostip port?

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Describe the solution you'd like A clear and concise description of what you want to happen.
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
Additional context Add any other context or screenshots about the feature request here.

try to telnet hostip port?

DB-gpt的服务器是能连接到其他远程服务器的mysql的

+1，我也是这个错

authors: Aries-ckt dencentding paul-yangmy

repo: eosphoros-ai/DB-GPT

license: MIT


text:
Question: Upcoming view, one line event

Hi Sean,
Can I make eventTitle and eventTime appear in the same line in Upcoming view? I have enough width and limited height so it would be nice to save some space by displaying them in one line rather then broken down into two. Do you have a CSS trick to achieve this?
Cheers,
Gyorgy

Some more adjusting might be needed for your environment, but basic concept would be this;
.CX2 .upcoming .event .eventIcon {
  width:16px;
  height:16px;
  min-width:inherit;
  min-height:inherit;
}

.CX2 .upcoming .event .eventMain {
  display:flex;
  flex-direction:row;
  justify-content: space-between;
}

.CX2 .upcoming .event .eventTitle {
  width:45%;
}

.CX2 .upcoming .event .eventTime {
  width:45%;
}

I almost hit the right code. My guess was
.CX2 .upcoming .event {
  display:flex;
  flex-direction:row;
  justify-content: space-between;
}

but missed out .eventMain .
Thank you!

authors: GattoJohnny eouia


text:
[Marketplace]  model/applications icon are changed to default icon on the 'Conversation list' panel. They are restored after refresh and switching to DIAL Marketplace and return back

EPAM AI DIAL chat version
0.18.0
What happened?
[Marketplace] after deploy model/applications icon are changed to default icon on the 'Conversation list' panel. They are restored after refresh and switching to DIAL Marketplace and return back

Confidential information

[X] I confirm that do not share any confidential information

Case 2:
Steps:

Duplicate any chat from Organization
Refresh page -> 2 duplicated chats displayed , name changed to model name
Refresh page -> default icons are displayed for all models

https://github.com/user-attachments/assets/415a8f02-ca55-4edb-b14c-74ef3ed8f6c1

authors: VolhaBazhkova YauheniyaH

repo: epam/ai-dial-chat


text:
Copy/Cut/Paste for any Arrow. If copy any arrow and past- Arrow Open Angle always pasted

Steps to Reproduce

Copy/Cut any arrow (equilibrium arrow for example)
Paste (Ctrl+V)

Expected behavior
The Copied  arrow is pasted
Actual behavior
Arrow Open Angle always pasted
Screenshots
https://user-images.githubusercontent.com/93334478/143858593-0a5bd441-ad01-4be6-b57c-b1f887e25ab1.mp4
Desktop (please complete the following information):

OS:Windows 10
Browser: Chrome Version 93.0.4577.63, Firefox Version 94.0.1, Microsoft Edge Version 93.0.961.47

Fixed, tested v. 2.4

repo: epam/ketcher


text:
Add minor indicators in shift box and disposition

Fixes #738

Coverage decreased (-0.02%) to 86.929% when pulling a6341dd9d4a7e594af2d5d51c14f0f1fd2dfa85f on minor-indicator into ca1543adfcbdbc0736ece3ee7da2dbcf28235ac0 on main.

authors: coveralls felixrindt

repo: ephios-dev/ephios


text:
error in console hex2rgb is null on certain colors on hover of a va-button

Is there a way to set a jsfiddle using vuestic?
I have this code in template
<va-button flat color="green" icon="fa fa-eye" />
<va-button flat color="orange" icon="fa fa-eye" />

When I hover the green button, I get an error in the Firefox console :
  [Vue warn]: Error in render: "TypeError: hex2rgb(...) is null"

Nothing happens when I hover the orange button.
I am using TopBar, the problem maybe comes from, in TopbarLink.vue:
import { getHoverColor } from './../../../../services/color-functions'

which doesn't import hex2rgb from the same file?
If I change the color green with #080 the button's color is almost the same, the console error doesn't appear anymore but a green background appears on hover.

Hi.
Vuestic admin version, vuestic-ui version and fiddle itself will be appreciated. Currently not enough data.

$ npm list | grep vuestic
├─┬ vuestic-ui@0.1.8

Can you show me a fiddle example using vuestic?

Still not sure how do I reproduce the problem.
Fiddle-wise, I do not expect vuestic to work all too well, as components are transpiled on build, which means importing from cdn won't be an option. Codesanbox might work though.

authors: asvae grippon

repo: epicmaxco/vuestic-admin


text:
Speed up dev server startup

I don't know what's making the dev server take multiple seconds to start up, but I want it to be much faster (instant).
This is open for anyone to troubleshoot.

epic-stack server/index.js time is only 25ms
You should probably look at Remix.
When it log info built (3.3s) the actual time is about 2 seconds more.

I wonder if it would be possible to do some things in parallel. Maybe the server can start accepting traffic but hold off on responding until the build is ready? That would at least make it easier during development to start opening the app immediately even if it doesn't respond right away.

There is a dev server warning about totp being ESM now, unsure if related. dev server also does pre-build step which might only need to happen once, not everytime a dev server is started

That's a false warning. The Remix team is going to be removing it in the next version.

this seems to be slow boot when using express

I wouldn't mind switching from express. But we'd need to support all the things we do in express with whatever else we use.

authors: kentcdodds onemen vinstah

repo: epicweb-dev/epic-stack


text:
Adding additional subnational estimates.

We are interested in supporting an increased range of subnational estimates. Ideally, contributors will be able to do the majority of the linking work in order for the core team to focus on optimizing the code and theoretical considerations. In order for this to be possible, we need several things.

Whilst we would like to support estimates for as many places as possible it is key that areas with the fewest other resources/greatest need are prioritized. Users should be encouraged to open an issue highlighting the subnational area they would like estimates to be produced for, flag the available data, and outline to what level they are able to contribute towards the necessary integration steps. At this time we are unlikely to be able to provide subnational estimates below the level 1 geographic region. Though we would be happy to support external implementations.
Users need to be linked to covidregionaldata and in particular the SMG which outlines the steps required for adding subnational datasets. This step is required in order for us to support estimates.
Users need to be provided with documentation on how to add a new subnational estimate to this repo.
Ideally once a new subnational estimate has been added it will be tested with the results explored before entering daily production.

We will try and tick off task 3 as part of PR #17 as that brings in a new file for defining the regions. This also introduces a "stable" attribute to each location that can be used for adding a new location for test purposes but not including it in any scheduled runs (a mechanism for task 4).

Looks like this is complete to me. Thanks to @joeHickson and @JAllen42 !

authors: joeHickson seabbs

repo: epiforecasts/covid-rt-estimates