Nice!

In D3237#87734, @ashoat wrote:

Sounds like we need to add something like brew install pkgconfig to our dev environment setup instructions

Rebased and addressed comments

• Address review comments

In D3198#89776, @ashoat wrote:

Requesting changes for @jimpo's last comment above. Remember – if you don't request changes / accept when you leave a comment, then the diff stays on your queue instead of going back to the diff author's!

In D3198#86520, @karol-bisztyga wrote:

Can you specify what do you mean exactly? I think folly is installed as a system lib and symlinked to the local dir.

In D3268#89591, @karol-bisztyga wrote:

Is there a task for this?

Cool! I'm a nix n00b, so forgive any dumb comments. :-)

Good idea. There are a couple other improvements possible now, in particular building gRPC with the -DgRPC_SSL_PROVIDER=package and -DgRPC_ZLIB_PROVIDER=package flags to avoid building BoringSSL and rebuilding zlib and instead use the system libs installed in the base image.

@ashoat Agreed that the whitespace around private: is weird because gRPC v1.39.1 (what is installed) is pinned to protobuf 3.15.8. In another local branch I tried installing protoc 3.15.8 explicitly in the Docker image per the directions (not with CMake) and the same thing happens.

@karol-bisztyga I'll rebase after D3234 lands or is rejected so you can patch and test yourself

The full diff from the new generated files in D3238 is

In D3200#86984, @karol-bisztyga wrote:

This is the old approach, the new one uses some kind of local instance of the cloud. I'm not sure but I might've put this up before we talked about this in the channel. I think we can land this and refactor the dev mode separately https://linear.app/comm/issue/ENG-795/use-local-cloud-instance-for-dev-mode-in-services

@karol-bisztyga Rebased, you should be able to patch now

@atul This should run rm -rf /var/lib/apt/lists/* after the apt-get install. See https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#apt-get. "In addition, when you clean up the apt cache by removing /var/lib/apt/lists it reduces the image size, since the apt cache is not stored in a layer."

• Fix blob service base to not depend on tunnelbroker

@karol-bisztyga No, the generated files are not the same as in https://github.com/CommE2E/comm/tree/master/native/cpp/CommonCpp/grpc/_generated. However, I checked that they are the same as the generated files in the tunnelbroker server Docker container on master currently, which consequently does not match the client files.

What environments are supported? pkg-config is pretty common in Linux and can be installed with homebrew on OSX I believe.

Yes, waiting for response from @karol-bisztyga

Given that this is just a change to the environment, I think testing that the image builds and the container can be launched with the service running is a good enough test. Though this diff in the stack in particular is more of a proposal and maybe should be delayed until a similar change is ready for the other services so that they all have the same code structure.

Yes, it doesn't actually source into environment variables but parses it as a file. So if you actually set the environment variables, they will override whatever is in the file. And for different configurations you can pass the --env-file flag explicitly. See https://docs.docker.com/compose/env-file/.

Only one comment

OK, a related issue here is that I'd prefer folly to be built and installed as a system library instead of pulled into the CMake build of the service. This both helps for Docker layer caching and simplifying the CMakeLists.txt. I don't care as much whether it's in the service image or the base image, but one argument for service image is that we may want to build folly with different features/flags/build parameters for different services.

LGTM

I don't love the idea of having a third config file (.aws/credentials & tunnelbroker.ini already). Why is .aws/credentials not good enough? What does the CLI have to do with the application config?

For session keys and things like that, std::random_device is fine. If perf is an issue we could make a using Crypto++ primitives.

I don't understand the problem here.