Goma with Bazel Buildfarm

1,299 views
Skip to first unread message

Bryce Thomas

unread,
May 9, 2019, 2:33:51 AM5/9/19
to infra-dev
Hi folks,

I'm assessing what it would take to get the Goma server working with Bazel
Buildfarm for remote execution. I wanted to get some feedback on whether I'm on
the right track, and any major implementation considerations I might be missing.
My current focus is getting a running prototype of the Goma client, server, and
Buildfarm working together: if all the components run on one machine, that's
fine for now.

If my understanding is correct, below is the minimum Goma + RBE setup, and what
a minimum Goma + Bazel Buildfarm would look like ("[]" to enclose components
running on the same machine):

[Goma client -> Goma server] --Remote Execution API--> [RBE server(?)] -> [RBE worker]
[Goma client -> Goma server  --Remote Execution API--> Buildfarm server -> Buildfarm worker]

Is the above correct?

My next question pertains to auth.  My understanding is that there's two forms
of auth going on:

1. Goma client authenticates with Goma server to simply say "I own this email
  address, Google says so".  The email whitelist the Goma server is started with
  (--whitelisted-users flag) then determines whether that user is authorized.
2. Goma server authenticates with RBE using a GCP service account
  (--service-account-json flag).

For a prototype, I don't see any reason to remove 1, and perhaps if Buildfarm
server is setup without authentication it will simply ignore any auth
information transmitted as part of 2 (I'm not sure what this looks like on the
wire: maybe a HTTP Authorization header or similar)?  Does that sound correct?
In other words, is it likely to be possible to get a Buildfarm prototype running
without removing/modifying any of the Goma auth code?

Regarding Buildfarm server: is it correct to say that clients can only
communicate with it over HTTP/2?  I notice that when curling the Buildfarm
server it returns "Unexpected HTTP/1.x request: GET /".  I'm guessing this means
either the Buildfarm server will need to be configured somehow to present a
valid certificate, or the Goma server code modified to not enforce certificate
checks?

Finally, is there anything else either RBE or Goma-specific in the communication
between Goma server and RBE, or is it a purely an implementation of the Remote
Execution API protocol?  Any other major pieces I'm missing?

Many thanks.

Marc-Antoine Ruel

unread,
May 9, 2019, 8:20:05 PM5/9/19
to Bryce Thomas, infra-dev
Hi!

Le jeu. 9 mai 2019, à 02 h 33, 'Bryce Thomas' via infra-dev <infr...@chromium.org> a écrit :
Hi folks,

I'm assessing what it would take to get the Goma server working with Bazel
Buildfarm for remote execution. I wanted to get some feedback on whether I'm on
the right track, and any major implementation considerations I might be missing.
My current focus is getting a running prototype of the Goma client, server, and
Buildfarm working together: if all the components run on one machine, that's
fine for now.

If my understanding is correct, below is the minimum Goma + RBE setup, and what
a minimum Goma + Bazel Buildfarm would look like ("[]" to enclose components
running on the same machine):

[Goma client -> Goma server] --Remote Execution API--> [RBE server(?)] -> [RBE worker]

That's what we do.
In our case we cannot run the RBE server nor the worker on the same machine because it runs on Google production infrastructure.
 
[Goma client -> Goma server  --Remote Execution API--> Buildfarm server -> Buildfarm worker]

Is the above correct?

I suppose the later could be made to work. I am not personally aware of such usage yet.

My next question pertains to auth.  My understanding is that there's two forms
of auth going on:

1. Goma client authenticates with Goma server to simply say "I own this email
  address, Google says so".  The email whitelist the Goma server is started with
  (--whitelisted-users flag) then determines whether that user is authorized.
2. Goma server authenticates with RBE using a GCP service account
  (--service-account-json flag).

As far as I know this is correct.

For a prototype, I don't see any reason to remove 1, and perhaps if Buildfarm
server is setup without authentication it will simply ignore any auth
information transmitted as part of 2 (I'm not sure what this looks like on the
wire: maybe a HTTP Authorization header or similar)?  Does that sound correct?
In other words, is it likely to be possible to get a Buildfarm prototype running
without removing/modifying any of the Goma auth code?

Removing authentication is not a goal for us.

Regarding Buildfarm server: is it correct to say that clients can only
communicate with it over HTTP/2?  I notice that when curling the Buildfarm
server it returns "Unexpected HTTP/1.x request: GET /".  I'm guessing this means
either the Buildfarm server will need to be configured somehow to present a
valid certificate, or the Goma server code modified to not enforce certificate
checks?

gRPC requires HTTP/2. See https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md for more details.
 
Finally, is there anything else either RBE or Goma-specific in the communication
between Goma server and RBE, or is it a purely an implementation of the Remote
Execution API protocol?  Any other major pieces I'm missing?

Fumitoshi Ukai (鵜飼文敏)

unread,
May 10, 2019, 2:40:37 AM5/10/19
to Marc-Antoine Ruel, Bryce Thomas, infra-dev
goma server uses  grpc.WithPerRPCCredentials for auth to RE API.
if you don't specify --service-account-json flag, default account credential will be used (by google.FindDefaultCredentials).

If buildfarm doesn't setup any auth, how about just using default account credential? any credentials will be accepted by your buildfarm backend?


Regarding Buildfarm server: is it correct to say that clients can only
communicate with it over HTTP/2?  I notice that when curling the Buildfarm
server it returns "Unexpected HTTP/1.x request: GET /".  I'm guessing this means
either the Buildfarm server will need to be configured somehow to present a
valid certificate, or the Goma server code modified to not enforce certificate
checks?

gRPC requires HTTP/2. See https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md for more details.

goma server also use TLS with grpc.WithTransportCredentials
better to have option for insecure mode? (grpc.WithInsecure)
 
 
Finally, is there anything else either RBE or Goma-specific in the communication
between Goma server and RBE, or is it a purely an implementation of the Remote
Execution API protocol?  Any other major pieces I'm missing?

I don't understand the question. It's using the API as exposed at https://godoc.org/github.com/bazelbuild/remote-apis/build/bazel/remote/execution/v2.

It just use the public API, but might uses Google Cloud RBE specific features, or undocumented behavior.

-- 
ukai

 


M-A

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To post to this group, send email to infr...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CANAQWOX7uL3SFceHkHcw7%2Bz_MfBPs1O11V2_zaxXukc-BKN5pg%40mail.gmail.com.

Bryce Thomas

unread,
May 14, 2019, 11:58:12 PM5/14/19
to infra-dev, mar...@chromium.org, br...@amazon.com
I note the Goma server seems to dispatch execute jobs inside a wrapper script
that assumes the RE API worker is running inside a Docker container (L513:565):

I'm not sure I fully understand what assumptions this makes about the worker
environment.  By the looks of it, it assumes that a volume has been mounted in
the Docker container so writes to the $(pwd) carry through to the file system of
the Docker host.  From there, it looks like there's a new docker container spun
up from within the first container (docker in docker) for every execute job
here:
It looks like the volume is essentially being "forwarded on" here to provide
write access back to the host from the inner Docker container.

Is the "outer" docker container ephemeral (per execute job) like the inner
docker container, or does it persist across execute jobs?  Is there a near-term
plan to factor this code out of the Goma server so as not to assume the worker
is running inside of Docker?  I see some hint of that in this comment:
To unsubscribe from this group and stop receiving emails from it, send an email to infr...@chromium.org.

Fumitoshi Ukai (鵜飼文敏)

unread,
May 15, 2019, 12:30:36 AM5/15/19
to Bryce Thomas, infra-dev, Marc-Antoine Ruel
This code is required to run command at the same directory as client uses (for building debug obj).  It's not used to build release obj.

RE API has no way to specify a directory of the input root.  However, debug obj might contain debug info using absolute directory.  To mount input root as same as client sees, we need to run sibling docker to mount it on specific directory.
Both docker (inner and outer) are ephemeral; per execute job.

From: 'Bryce Thomas' via infra-dev <infr...@chromium.org>
日付: 2019年5月15日(水) 12:58
To: infra-dev
Cc: <mar...@chromium.org>, <br...@amazon.com>

I note the Goma server seems to dispatch execute jobs inside a wrapper script
that assumes the RE API worker is running inside a Docker container (L513:565):

I'm not sure I fully understand what assumptions this makes about the worker
environment.  By the looks of it, it assumes that a volume has been mounted in
the Docker container so writes to the $(pwd) carry through to the file system of
the Docker host.  From there, it looks like there's a new docker container spun
up from within the first container (docker in docker) for every execute job
here:
It looks like the volume is essentially being "forwarded on" here to provide
write access back to the host from the inner Docker container.

Is the "outer" docker container ephemeral (per execute job) like the inner
docker container, or does it persist across execute jobs?  Is there a near-term
plan to factor this code out of the Goma server so as not to assume the worker
is running inside of Docker?  I see some hint of that in this comment:

Hmm, 
Ok. I'll change to put in container name.
 
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/7b017573-00f8-4dec-ac20-30bedca72a85%40chromium.org.

Fumitoshi Ukai (鵜飼文敏)

unread,
May 23, 2019, 1:47:11 AM5/23/19
to Bryce Thomas, infra-dev, Marc-Antoine Ruel
Hi,


If your container image has /opt/goma/bin/run-at-dir.sh, it will be used as wrapper script.
It will get $INPUT_ROOT_DIR and $WORK_DIR as environment variables.  It is expected to re-mount current dir at $INPUT_ROOT_DIR, change directory to $INPUT_ROOT_DIR/$WORK_DIR and run command.
not tested, but something like

     #!/bin/bash
     set -e
     mkdir -p "${INPUT_ROOT_DIR}"
     sudo mount --bind "$(pwd)" "${INPUT_ROOT_DIR}"
     cd "${INPUT_ROOT_DIR}/${WORK_DIR}"
     exec "$@"

or, If you don't care too much about debug information, the following script would be ok
   #!/bin/bash
   cd ./$WORK_DIR
   exec "$@"

Also, remoteexec_proxy add new flag -insecure-remoteexec.  If it is specified, remoteexec_proxy will talk RE API without TLS.  Hope that helps.

2019年5月15日(水) 13:30 Fumitoshi Ukai (鵜飼文敏) <uk...@google.com>:

Bryce Thomas

unread,
May 28, 2019, 6:56:37 PM5/28/19
to infra-dev, br...@amazon.com, mar...@chromium.org
Thanks Fumitoshi!  Those are some really useful additions.
To unsubscribe from this group and stop receiving emails from it, send an email to infr...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/7b017573-00f8-4dec-ac20-30bedca72a85%40chromium.org.

Jakub Lason

unread,
Jun 12, 2019, 3:56:28 AM6/12/19
to infra-dev
Hi guys,

I've been observing this thread for a while looking for a hints while trying to make Goma work with BazelBuildFarmas well. Finally, it seems to work. I even managed to replicate the docker setup that is expected by the original wrapper script so entire stack runs almost without changes to either proxy or RE backend code. There are however still two issues that I had to hot fix in order to make it running:

- the -insecure-remoteexec flag seems to be necessary as it looks like Bazel BuildFarm does not support SSL. However, there is a code in a proxy (https://chromium.googlesource.com/infra/goma/server/+/refs/heads/master/remoteexec/adapter.go#151) that adds gRPC credentials to the (now) insecure channel. This is rejected by the gRPC framework as credentials cannot be used over insecure channel. As a result the connection to the RE backend cannot be established. (for now, I simply patched the adapter.go and commented out the problematic code)

- when using GOMA_ARBITRARY_TOOLCHAIN_SUPPORT the compiler binary is sent together with other inputs. However, when the compiler is a symlink (ie: clag++ -> clang) the backend gets only the symlink target binary while the command line still refers to the original symlink name (ie. clang binary is uploaded to the RE backend but command line still refers the clang++). It looks like both entries (clang and clang++) are included (one as binary, the second one as a symlink) in ToolchainSpec of ExecReq that goes from client to proxy. Later, proxy drops the symlink from inputs that will be pushed to the RE backend (https://chromium.googlesource.com/infra/goma/server/+/refs/heads/master/remoteexec/exec.go#276) and the missing tool will cause the remote compilation to fail. I wonder if in a case when GOMA_ARBITRARY_TOOLCHAIN_SUPPORT is on the client should resolve all symlinks and send only the link target binary under the name of the symlink (so clang++ is resolved to clang first and later the clang binary is sent with the name of clang++)?

/Kuba

Mostyn Bramley-Moore

unread,
Jun 12, 2019, 4:13:44 AM6/12/19
to Jakub Lason, infra-dev
Symlink handling is a weak point of Goma IMO- the simplest solution is to avoid using them, eg by instead using hardlinks or copies.

-Mostyn.
 
/Kuba

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.

To post to this group, send email to infr...@chromium.org.

Yoshisato Yanagisawa

unread,
Jun 12, 2019, 5:51:58 AM6/12/19
to Mostyn Bramley-Moore, Jakub Lason, infra-dev


2019年6月12日(水) 17:13 Mostyn Bramley-Moore <mos...@vewd.com>:
On Wed, Jun 12, 2019 at 9:56 AM Jakub Lason <ku...@opera.com> wrote:
Hi guys,

I've been observing this thread for a while looking for a hints while trying to make Goma work with BazelBuildFarmas well. Finally, it seems to work. I even managed to replicate the docker setup that is expected by the original wrapper script so entire stack runs almost without changes to either proxy or RE backend code. There are however still two issues that I had to hot fix in order to make it running:

- the -insecure-remoteexec flag seems to be necessary as it looks like Bazel BuildFarm does not support SSL. However, there is a code in a proxy (https://chromium.googlesource.com/infra/goma/server/+/refs/heads/master/remoteexec/adapter.go#151) that adds gRPC credentials to the (now) insecure channel. This is rejected by the gRPC framework as credentials cannot be used over insecure channel. As a result the connection to the RE backend cannot be established. (for now, I simply patched the adapter.go and commented out the problematic code)

- when using GOMA_ARBITRARY_TOOLCHAIN_SUPPORT the compiler binary is sent together with other inputs. However, when the compiler is a symlink (ie: clag++ -> clang) the backend gets only the symlink target binary while the command line still refers to the original symlink name (ie. clang binary is uploaded to the RE backend but command line still refers the clang++). It looks like both entries (clang and clang++) are included (one as binary, the second one as a symlink) in ToolchainSpec of ExecReq that goes from client to proxy. Later, proxy drops the symlink from inputs that will be pushed to the RE backend (https://chromium.googlesource.com/infra/goma/server/+/refs/heads/master/remoteexec/exec.go#276)

As far as I understand, symlinks are not regular file.  They won't be marked as a regular file to be uploaded.  Thus, I think this is intended behavior.
 
and the missing tool will cause the remote compilation to fail. I wonder if in a case when GOMA_ARBITRARY_TOOLCHAIN_SUPPORT is on the client should resolve all symlinks and send only the link target binary under the name of the symlink (so clang++ is resolved to clang first and later the clang binary is sent with the name of clang++)?


I think goma server code create merkle tree with symlinks.

Please fix me if I misunderstand Bazel BuildFarm or if I see wrong code base, but I suppose it does not support symlinks?
I am not confident but fetchInput sounds like fetching input files and directories.
Yes, it create files.
also it create directories.

However, where is symlink?
I believe Directory should have symlinks in its member.
 
Symlink handling is a weak point of Goma IMO- the simplest solution is to avoid using them, eg by instead using hardlinks or copies.


I do not remember the actual symlink issues, but I feel Goma client is not good at handling wrappers.  Also, its compiler dependencies selection has some rooms of improvement.  Mostyn might have filed an issue on latter case (without -B, binutils are ignored for gcc).  Sorry for not tacking that due to the priority.
 
-Mostyn.
 
/Kuba

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To post to this group, send email to infr...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/dd1f35f6-c23e-4e5e-9102-2f92312e7f7d%40chromium.org.


--
Mostyn Bramley-Moore
Vewd Software

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To post to this group, send email to infr...@chromium.org.

Jakub Lason

unread,
Jun 12, 2019, 6:24:06 AM6/12/19
to infra-dev, mos...@vewd.com, ku...@opera.com
Good catch! 
I looked at the FileNode in the RE API spec as I assumed some kind of symlink flag will be there. Mea culpa. Thanks.

/K

 

Moore, Justin1

unread,
Jun 14, 2019, 10:00:53 AM6/14/19
to Yoshisato Yanagisawa, Mostyn Bramley-Moore, Jakub Lason, infra-dev

Hi all,

 

I am hitting a road block when running the command from the GOMA server documentation:

 

autoninja –C out/Release obj/base/base64.o

 

I am using GOMA with Bazel BuildGrid, I am receiving an ERROR message that the request size sent is to large (larger than 4MB) which is the default request size limit set by protobuf.

 

Has anyone else encountered this issue and is there a work around? I have made changes to increase the size on both GOMA and BuildGrid to no avail, suggesting that the protobuf max request size has to be changed?

 

Any help is appreciated

 

Thank you,

Justin

Fumitoshi Ukai (鵜飼文敏)

unread,
Jun 16, 2019, 11:48:54 PM6/16/19
to Moore, Justin1, Yoshisato Yanagisawa, Mostyn Bramley-Moore, Jakub Lason, infra-dev


2019年6月14日(金) 23:00 Moore, Justin1 <justin...@intel.com>:

Hi all,

 

I am hitting a road block when running the command from the GOMA server documentation:

 

autoninja –C out/Release obj/base/base64.o

 

I am using GOMA with Bazel BuildGrid, I am receiving an ERROR message that the request size sent is to large (larger than 4MB) which is the default request size limit set by protobuf.

 

Has anyone else encountered this issue and is there a work around? I have made changes to increase the size on both GOMA and BuildGrid to no avail, suggesting that the protobuf max request size has to be changed?


Hmm, I think either side should set size limit, and Google Remote Build Execution does and goma server doesn't.
I'll change goma server also sets size limit.
 

Fumitoshi Ukai (鵜飼文敏)

unread,
Jun 17, 2019, 12:34:40 AM6/17/19
to Moore, Justin1, Yoshisato Yanagisawa, Mostyn Bramley-Moore, Jakub Lason, infra-dev


2019年6月17日(月) 12:48 Fumitoshi Ukai (鵜飼文敏) <uk...@google.com>:


2019年6月14日(金) 23:00 Moore, Justin1 <justin...@intel.com>:

Hi all,

 

I am hitting a road block when running the command from the GOMA server documentation:

 

autoninja –C out/Release obj/base/base64.o

 

I am using GOMA with Bazel BuildGrid, I am receiving an ERROR message that the request size sent is to large (larger than 4MB) which is the default request size limit set by protobuf.

 

Has anyone else encountered this issue and is there a work around? I have made changes to increase the size on both GOMA and BuildGrid to no avail, suggesting that the protobuf max request size has to be changed?


Hmm, I think either side should set size limit, and Google Remote Build Execution does and goma server doesn't.
I'll change goma server also sets size limit.

Ah, I think goma server limits to cache_capabilities.max_batch_total_size_bytes for BatchUpdateBlobs.

Which RPC exceeds 4MB limit?

Fumitoshi Ukai (鵜飼文敏)

unread,
Jun 26, 2019, 1:13:39 AM6/26/19
to Moore, Justin1, Yoshisato Yanagisawa, Mostyn Bramley-Moore, Jakub Lason, infra-dev
Hi,

I've just release go.chromium.org/goma/ser...@v0.0.4, which includes fix that it wouldn't set cred on insecure grpc conn.

2019年6月17日(月) 13:34 Fumitoshi Ukai (鵜飼文敏) <uk...@google.com>:

Venkatesh Srinivas

unread,
Aug 5, 2019, 5:06:07 PM8/5/19
to infra-dev
On Wednesday, June 12, 2019 at 2:56:28 AM UTC-5, Jakub Lason wrote:
Hi guys,

I've been observing this thread for a while looking for a hints while trying to make Goma work with BazelBuildFarmas well. Finally, it seems to work. I even managed to replicate the docker setup that is expected by the original wrapper script so entire stack runs almost without changes to either proxy or RE backend code. There are however still two issues that I had to hot fix in order to make it running:

Do you happen to have any notes on how you set this up and how you replicated the docker setup in particular?

Thanks,
-- vs; 

Jakub Lason

unread,
Aug 28, 2019, 3:03:38 AM8/28/19
to Venkatesh Srinivas, infra-dev
On Mon, Aug 5, 2019 at 11:06 PM 'Venkatesh Srinivas' via infra-dev <infr...@chromium.org> wrote:

Do you happen to have any notes on how you set this up and how you replicated the docker setup in particular?


The command from the client comes wrapped by the proxy wrapper script so whatever runs that script must meet all of its expectations (it requires properly initialized environment and certain docker volumes to be set). In order to meet the proxy wrapper script requirements I've set up another wrapper script - this time in bazel's worker config. This script is run by the bazel worker for every single command that is sent to the worker. Here's the bazel worker wrapper script:

toolchain=`cat /tmp/toolchain`

# exec root is at PWD set by the worker.
exec_root="$(pwd)"

docker run \
 -e INPUT_ROOT_DIR=${INPUT_ROOT_DIR} \
 -e WORK_DIR=${WORK_DIR} \
 -u "$(id -u)" \
 --volume "${exec_root}:${exec_root}" \
 --workdir "${exec_root}" \
 --volume /var/run/docker.sock:/var/run/docker.sock \
 --rm \
 "${toolchain}" \
 "$@"

Basically is sets the environment and proper volumes so the proxy wrapper script can use them. This piece of code was simply reverse engineered to make the proxy script happy. It was good enough for the demo setup.

/Kuba

arvind bhande

unread,
Feb 27, 2020, 1:55:24 PM2/27/20
to infra-dev
Hi guys,

It seems that goma client, server is working with bazelbuilf farm, can anyone help with goma changes required to make it work with bazelbuild farm?

Thanks,
AB

Jakub Lason

unread,
Feb 28, 2020, 2:51:43 AM2/28/20
to arvind bhande, infra-dev
It has been a while since the initial discussion. At that time bazel-buildfarm was my first attempt to establish working goma backend. All the changes needed to make it running were described in this thread and some of them were even fixed in the goma server code. However, since bazel-buildfarm missed few RBE features I shifted towards buildgrid and finally managed to setup working goma cluster. There were few changes needed to both: buildgrid and goma proxy (mostly related to configuration, not to the RBE itself). I did not submit any patches yet (I'm sure not all of them are going to be accepted anyway) but it may be possible that forks of buildgrid and goma may be published some time in the future.

For now I can tell that buildgrid is far easier to use than bazel-buildfarm. I heard some rumors that others are trying to make goma work with buildbarn (which at first glance looked promising too). From current perspective I'd not go with bazel-buildfarm. I'm not saying it is bad (I never tested it in production environment) but it was certainly more difficult to analyze and debug.

--
Kuba Lasoń
Opera Software


--
You received this message because you are subscribed to a topic in the Google Groups "infra-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/infra-dev/-6qIunOC-BI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to infra-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/5186a3d1-ad83-462c-8981-eeb7945a1067%40chromium.org.

Bryce Thomas

unread,
Apr 30, 2020, 6:22:10 PM4/30/20
to infra-dev
Today I received notice via email that Google Cloud RBE alpha program is ending June 30 2020, and that RBE will _not_ proceed towards General Availability.  Is this expected to have any impact on Google's support for the open-source Goma server?  For example, will this lead to more or less Google resources being dedicated to the Goma server and open-source backend alternatives?  Is Google open to contributions that will help build a viable out-of-the-box end-to-end alternative to RBE?

Haitao Feng

unread,
May 12, 2020, 4:59:06 AM5/12/20
to infra-dev, arvind...@yahoo.co.in
Have you posted the patches and steps somewhere to make goma client + goma server + buildgrid work?

Jakub Lason

unread,
May 12, 2020, 2:18:58 PM5/12/20
to Haitao Feng, infra-dev, arvind bhande
Nope, not yet. Mostly because I had to drop Buildgrid as RBE backend. Unfortunately, Buildgrid had some scalability problems. It worked pretty well with ca. 40 workers but started to choke when deployed on a much larger scale with goma proxy sending it hundreds of requests per sec. Finaly, I ended up writing my own RBE backend in Go (which surprisingly wasn't that complicated after all). I'd like to share my findings but I need to finish the deployment of our internal goma service first.

--
Kuba Lasoń
Opera Software

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/11206795-dd96-456e-adac-2570f6a2fbe4%40chromium.org.

Jakub Lason

unread,
Jun 9, 2020, 11:34:54 AM6/9/20
to infra-dev
Hi guys,

I've written a quick step by step guide for setting up a goma server with BuildGrid serving as a RBE backend. You can find it here: https://kubala.github.io. Hope it helps with bootstrapping your own goma service.


--
Kuba Lasoń
Opera Software

Ulf Adams

unread,
Jul 1, 2020, 4:10:53 PM7/1/20
to infra-dev
Are there any plans to make goma client talk directly to backends that support the REAPI?
>> To unsubscribe from this group and stop receiving emails from it, send an email to infr...@chromium.org.
Reply all
Reply to author
Forward
0 new messages