| commit | cdb8c78eb7d29e6595053c455141007cb1c13a83 | [log] [tgz] |
|---|---|---|
| author | Serge Bazanski <serge@nexantic.com> | Mon Feb 17 12:34:02 2020 +0100 |
| committer | Serge Bazanski <serge@nexantic.com> | Mon Feb 17 12:34:02 2020 +0100 |
| tree | db17ef01058c8185887e26e31131d62c168a23c7 | |
| parent | 6c8d5f9319706be576563b990c875afc0d60d02d [diff] |
Revamp DHCP, add basic context management This started off as a small change to make the network service DHCP client a bit nicer, and ended up basically me half-assedly starting to add context within Smalltown. In my opionion a simple OnStart/OnStop lifecycle management for services will stop working once we have to start handling failing services. I think taking inspiration from Erlang's OTP and implementing some sort of supervision tree is the way to go. I think this also ties nicely together with Go's context system, at least partially. Implementing the full supervision tree system is out of scope for this change, but at least this introduces .Context() on the base service struct that service implementations can use. Currently each service has its own background context, but again, this should tie into some sort of supervision tree in the future. There will be a design document for this. I also rejigger the init code to have a context available immediately, and use that to acquire (with timeout) information about DHCP addresses from the network service. I also fix a bug where the network service is started twice (once by init, once by the smalltown node code; now the smalltown node code takes in a dependency injected network service instead). I also fix a bug where OnStop would call OnStart. Whoops. Test Plan: no new functionality, covered by current tests Bug: T561 X-Origin-Diff: phab/D396 GitOrigin-RevId: adddf3dd2f140b6ea64eb034ff19533d32c4ef23
This is the monorepo storing all of nexantic's internal projects and libraries.
We assume a Fedora host system provisioned using rW, and IntelliJ as the IDE.
For better reproducibility, all builds are executed in containers.
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. All commands run inside the container, and necessary paths are mapped into the container.
We check the entire .ijwb project directory into the repository, which requires everyone to use the latest version of both IntelliJ and the Bazel plugin, but eliminates manual setup steps.
The following steps are necessary:
Install Google's official Bazel plugin in IntelliJ.
Add the absolute path to your ~/.cache/bazel-nxt folder to your idea64.vmoptions (Help → Edit Custom VM Options) and restart IntelliJ:
-Dbazel.bep.path=/home/leopold/.cache/bazel-nxt
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.
Open the .ijwb folder as IntelliJ project.
Disable Vgo support for the project.
Run a non-incremental sync in IntelliJ
The plugin will automatically resolve paths for generated files.
If you do not use IntelliJ, you need to use the scripts/bazel_copy_generated_for_ide.sh script to copy files locally.