| commit | 58cf3bca19e0d04a5dda6ad32a72459bb03df3cf | [log] [tgz] |
|---|---|---|
| author | Serge Bazanski <serge@monogon.tech> | Wed Mar 09 20:33:36 2022 +0100 |
| committer | Sergiusz Bazanski <serge@monogon.tech> | Fri Mar 11 11:40:50 2022 +0000 |
| tree | 5c11fb1f25eae37790ef870b1b937bfe6302674b | |
| parent | ec19b60842e905a4400e5f8b46b783a54d0a025a [diff] |
m/n/core: remove local listener from curator While working on a client library to access a cluster reliably, a thought popped into my head: Do we even need to run the local (UNIX domain socket) listener in the Curator? And, after checking all code paths, to my surprise... no, not really. Why did we ever do it? Perhaps because we started differently structured cluster bootstrap codebase that caused it to be a hard requirement. Or maybe it was just a momentary lapse of reason. Regardless, with the current codebase, it makes no sense: we always have Node credentials available, and we run the Curator on all network interfaces. So why not just connect over loopback and use TLS? Here are some of the benefits of removing the local listener: It removes a whole bunch of code, and pulling at a few more threads in the Curator and RPC codebases will probably let us remove quite a bit more now unused abstractions. It leads to a more secure product, as we have one less privilege domain socket to worry about (although we still have the etcd one... but that's a whole different can of worms). And most importantly, it paves the way for a vastly simplified cluster client - one in which the transport is the same regardless of whether we connect to a local or remote curator. This should let us use bog standard gRPC load balancing / resolving extensions to reach the Curator in an idiomatic and robust way. Change-Id: I1fe9b04ba3b5f4e001050c25aec61a761077492f Reviewed-on: https://review.monogon.dev/c/monogon/+/624 Reviewed-by: Mateusz Zalega <mateusz@monogon.tech>
This is the main repository containing the source code for the Monogon Project.
This is pre-release software - feel free to look around, and check back later for our first release!
Our build environment requires a working Podman binary (your distribution should have one).
Spinning up: scripts/create_container.sh
Spinning down: scripts/destroy_container.sh
Running commands: scripts/run_in_container.sh <...>
Using bazel using a wrapper script: scripts/bin/bazel <...> (add to your local $PATH for convenience)
This repository is compatible with the IntelliJ Bazel plugin, which enables full autocompletion for external dependencies and generated code. All commands run inside the container, and necessary paths are mapped into the container.
The following steps are necessary:
Install Google's Bazel plugin in IntelliJ. On IntelliJ 2020.3 or later, you need to install a beta release of the plugin.
Add the absolute path to your ~/.cache/bazel-monogon folder to your idea64.vmoptions (Help → Edit Custom VM Options) and restart IntelliJ:
-Dbazel.bep.path=/home/leopold/.cache/bazel-monogon
Set "Bazel Binary Location" in Other Settings → Bazel Settings to the absolute path of scripts/bin/bazel. This is a wrapper that will execute Bazel inside the container.
Use File → Import Bazel project... to create a new project from .bazelproject.
After running the first sync, everything should now resolve in the IDE, including generated code.
Launch the node:
scripts/bin/bazel run //:launch
Run a kubectl command:
scripts/bin/bazel run //metropolis/cli/dbg -- kubectl describe
Run tests:
scripts/bin/bazel test //...