This is a mega-change, but attempting to split this up further is
probably not worth the effort.
Summary:
1. Bump up bazel, rules_go, and others.
2. Switch to new go target naming (bye bye go_default_library)
3. Move go deps to go.mod/go.sum, use make gazelle generate from that
4. Bump up Python deps a bit
And also whatever was required to actually get things to work - loads of
small useless changes.
Tested to work on NixOS and Ubuntu 20.04:
$ bazel build //...
$ bazel test //...
Change-Id: I8364bdaa1406b9ae4d0385a6b607f3e7989f98a9
Reviewed-on: https://gerrit.hackerspace.pl/c/hscloud/+/1583
Reviewed-by: q3k <q3k@hackerspace.pl>
instead of Python packages
As usual with Python sadness, the @pydeps wheels are built on the bazel
host, so stuffing them inside a container_image (or py_image) will cause
new and unexpected kinds of misery.
Change-Id: Id4e4d53741cf2da367f01aa15c21c133c5cf0dba
rules_pip has a new version [1] of their rule system, incompatible with the
version we used, that fixes a bunch of issues, notably:
- explicit tagging of repositories for PY2/PY3/PY23 support
- removal of dependency on host pip (in exchange for having to vendor
wheels)
- higher quality tooling for locking
We update to the newer version of pip_rules, rename the external
repository to pydeps and move requirements.txt, the lockfile and the
newly vendored wheels to third_party/, where they belong.
[1] - https://github.com/apt-itude/rules_pip/issues/16
Change-Id: I1065ee2fc410e52fca2be89fcbdd4cc5a4755d55
We seem to be hitting a bug where the encryptor doesn't initialize
because of a lacking gpg binary, and then crashes on .Close().
This should fix the issue, but is untested.
goroutine 70 [running]:
code.hackerspace.pl/hscloud/bgpwtf/cccampix/pgpencryptor/gpg.(*CLIEncryptor).Close(0x0)
bgpwtf/cccampix/pgpencryptor/gpg/gpg.go:144 +0x22
main.(*service).Encrypt(0xc000345e00, 0x16d13a0, 0xc00047f260, 0x1688400, 0xc00003d4a0)
bgpwtf/cccampix/pgpencryptor/main.go:132 +0x6f9
code.hackerspace.pl/hscloud/bgpwtf/cccampix/proto._PGPEncryptor_Encrypt_Handler(0x133bf00, 0xc000345e00, 0x16c6300, 0xc0000d6000, 0x2247b78, 0xc0001f8000)
bazel-out/k8-fastbuild/bin/bgpwtf/cccampix/proto/linux_amd64_stripped/ix_go_proto%/code.hackerspace.pl/hscloud/bgpwtf/cccampix/proto/ix.pb.go:1816 +0xad
google.golang.org/grpc.(*Server).processStreamingRPC(0xc000160c00, 0x16d6ce0, 0xc000161500, 0xc0001f8000, 0xc0004244e0, 0x21b00e0, 0xc0000c6ff0, 0x0, 0x0)
external/org_golang_google_grpc/server.go:1175 +0xacd
google.golang.org/grpc.(*Server).handleStream(0xc000160c00, 0x16d6ce0, 0xc000161500, 0xc0001f8000, 0xc0000c6ff0)
external/org_golang_google_grpc/server.go:1254 +0xcbe
google.golang.org/grpc.(*Server).serveStreams.func1.1(0xc000404770, 0xc000160c00, 0x16d6ce0, 0xc000161500, 0xc0001f8000)
external/org_golang_google_grpc/server.go:690 +0x9f
created by google.golang.org/grpc.(*Server).serveStreams.func1
external/org_golang_google_grpc/server.go:688 +0xa1
created by google.golang.org/grpc.(*Server).serveStreams.func1
external/org_golang_google_grpc/server.go:688 +0xa1
Change-Id: Idd167a120e157005f44d255a61ef13dc80e8eeed
We add a small IRR service for getting a parsed RPSL from IRRs. For now,
we only support RIPE and ARIN, and only the following attributes:
- remarks
- import
- export
Since RPSL/RFC2622 is fucking insane, there is no guarantee that the
parser, especially the import/export parser, is correct. But it should
be good enough for our use. We even throw in some tests for good
measure.
$ grpcurl -format text -plaintext -d 'as: "26625"' 127.0.0.1:4200 ix.IRR.Query
source: SOURCE_ARIN
attributes: <
import: <
expressions: <
peering: "AS6083"
actions: "pref=10"
>
filter: "ANY"
>
>
attributes: <
import: <
expressions: <
peering: "AS12491"
actions: "pref=10"
>
filter: "ANY"
>
>
Change-Id: I8b240ffe2cd3553a25ce33dbd3917c0aef64e804
Add sync script for camp IX.
This will likely be triggered externally from some sort of long-running
service.
Change-Id: I4ead566e4308d24fdb64e789a7ca0e3dbf0214fb
radex
q3k
informatic
implr
Serge Bazanski
lb5tr