rename repo to bumblebee

.github/workflows/release.yaml

@@ -5,6 +5,9 @@ on:
     types:
       - created
 
+env:
+  REGISTRY: ghcr.io
+
 jobs:
   release-assets:
     name: Github Release Assets
@@ -31,4 +34,20 @@ jobs:
         run: ls && make upload-github-release-assets
         env:
           GITHUB_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
-          TAGGED_VERSION: ${{ github.event.release.tag_name }}
+          TAGGED_VERSION: ${{ github.event.release.tag_name }}
+  build-and-push-image:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      packages: write
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v2
+
+      - name: Log in to the Container registry
+        uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9
+        with:
+          registry: ${{ env.REGISTRY }}
+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}

Makefile

@@ -2,7 +2,7 @@
 # Versioning
 #----------------------------------------------------------------------------------
 OUTDIR ?= _output
-HUB ?= "gcr.io/"
+HUB ?= "ghcr.io/solo-io"
 
 
 RELEASE := "true"
@@ -14,7 +14,7 @@ endif
 # This tag has the refs/tags prefix, which we need to remove here.
 export VERSION ?= $(shell echo $(TAGGED_VERSION) | sed -e "s/^refs\/tags\///" | cut -c 2-)
 
-LDFLAGS := "-X github.com/solo-io/ebpf/pkg/internal/version.Version=$(VERSION)"
+LDFLAGS := "-X github.com/solo-io/bumblebee/pkg/internal/version.Version=$(VERSION)"
 GCFLAGS := all="-N -l"
 
 SOURCES := $(shell find . -name "*.go" | grep -v test.go)
@@ -25,39 +25,39 @@ SOURCES := $(shell find . -name "*.go" | grep -v test.go)
 
 docker-build:
 #   may run into issues with apt-get and the apt.llvm.org repo, in which case use --no-cache to build
-#   e.g. `docker build --no-cache ./builder -f builder/Dockerfile -t $(HUB)gloobpf/bpfbuilder:$(VERSION)`
-	docker build ./builder -f builder/Dockerfile -t $(HUB)gloobpf/bpfbuilder:$(VERSION)
+#   e.g. `docker build --no-cache ./builder -f builder/Dockerfile -t $(HUB)/bumblebee-builder:$(VERSION)
+	docker build ./builder -f builder/Dockerfile -t $(HUB)/bumblebee-builder:$(VERSION)
 
-docker-push:
-	docker push gcr.io/gloobpf/bpfbuilder:$(VERSION) 
+docker-push: docker-build
+	docker push $(HUB)/bumblebee-builder:$(VERSION)
 
 #----------------------------------------------------------------------------------
 # CLI
 #----------------------------------------------------------------------------------
 
 
-$(OUTDIR)/ebpfctl-linux-amd64: $(SOURCES)
-	CGO_ENABLED=0 GOARCH=amd64 GOOS=linux go build -ldflags=$(LDFLAGS) -gcflags=$(GCFLAGS) -o $@ ebpfctl/main.go
+$(OUTDIR)/bee-linux-amd64: $(SOURCES)
+	CGO_ENABLED=0 GOARCH=amd64 GOOS=linux go build -ldflags=$(LDFLAGS) -gcflags=$(GCFLAGS) -o $@ bee/main.go
 
-.PHONY: ebpfctl-linux-amd64
-ebpfctl-linux-amd64: $(OUTDIR)/ebpfctl-linux-amd64.sha256
-$(OUTDIR)/ebpfctl-linux-amd64.sha256: $(OUTDIR)/ebpfctl-linux-amd64
-	sha256sum $(OUTDIR)/ebpfctl-linux-amd64 > $@
+.PHONY: bee-linux-amd64
+bee-linux-amd64: $(OUTDIR)/bee-linux-amd64.sha256
+$(OUTDIR)/bee-linux-amd64.sha256: $(OUTDIR)/bee-linux-amd64
+	sha256sum $(OUTDIR)/bee-linux-amd64 > $@
 
-$(OUTDIR)/ebpfctl-linux-arm64: $(SOURCES)
-	CGO_ENABLED=0 GOARCH=arm64 GOOS=linux go build -ldflags=$(LDFLAGS) -gcflags=$(GCFLAGS) -o $@ ebpfctl/main.go
+$(OUTDIR)/bee-linux-arm64: $(SOURCES)
+	CGO_ENABLED=0 GOARCH=arm64 GOOS=linux go build -ldflags=$(LDFLAGS) -gcflags=$(GCFLAGS) -o $@ bee/main.go
 
-.PHONY: ebpfctl-linux-arm64
-ebpfctl-linux-arm64: $(OUTDIR)/ebpfctl-linux-arm64.sha256
-$(OUTDIR)/ebpfctl-linux-arm64.sha256: $(OUTDIR)/ebpfctl-linux-arm64
-	sha256sum $(OUTDIR)/ebpfctl-linux-arm64 > $@
+.PHONY: bee-linux-arm64
+bee-linux-arm64: $(OUTDIR)/bee-linux-arm64.sha256
+$(OUTDIR)/bee-linux-arm64.sha256: $(OUTDIR)/bee-linux-arm64
+	sha256sum $(OUTDIR)/bee-linux-arm64 > $@
 
 .PHONY: build-cli
-build-cli: ebpfctl-linux-amd64 ebpfctl-linux-arm64
+build-cli: bee-linux-amd64 bee-linux-arm64
 
 .PHONY: install-cli
 install-cli:
-	CGO_ENABLED=0 go install -ldflags=$(LDFLAGS) -gcflags=$(GCFLAGS) ebpfctl/main.go
+	CGO_ENABLED=0 go install -ldflags=$(LDFLAGS) -gcflags=$(GCFLAGS) bee/main.go
 
 ##----------------------------------------------------------------------------------
 ## Release

README.md

@@ -3,11 +3,11 @@ Staging ground for solo-io eBPF work
 
 ## Getting Started
 
-The first step to get started is to install `ebpfctl` using one of the [installation](#Installation) techniques listed below.
+The first step to get started is to install `bee` using one of the [installation](#Installation) techniques listed below.
 
-`ebpfctl` is a tool which allows for easier development and running of `eBPF` programs. Specifically we allow users to run their `eBPF` probes without running any user space code. We accomplish this using a set of conventions, and a 
+`bee` is a tool which allows for easier development and running of `eBPF` programs. Specifically we allow users to run their `eBPF` probes without running any user space code. We accomplish this using a set of conventions, and a 
 
-Once `ebpfctl` has been installed we can go ahead an initialize our first `eBPF` probe! To do this let's head over to our [tutorial](TUTORIAL.md).
+Once `bee` has been installed we can go ahead an initialize our first `eBPF` probe! To do this let's head over to our [tutorial](TUTORIAL.md).
 
 
 ### BPF conventions
@@ -20,13 +20,13 @@ For more detailed examples of these, please see our [tutorial](#TUTORIAL.md). Th
 
 #### Maps
 
-As the `ebpfctl` runner is primarily targeted at observability, much of the user space functionality of the tool is centered around the maps. The extension of the maps allows our user space runner to interpret and process the data from these maps in a generic way. The 2 main types of maps which are supported at this time are `RingBuffer` and `HashMap`. There is some overlap in the functionality of the two within our runner, but also some important differences.
+As the `bee` runner is primarily targeted at observability, much of the user space functionality of the tool is centered around the maps. The extension of the maps allows our user space runner to interpret and process the data from these maps in a generic way. The 2 main types of maps which are supported at this time are `RingBuffer` and `HashMap`. There is some overlap in the functionality of the two within our runner, but also some important differences.
 
 **Important Note:** Currently all structs used in maps which are meant to be processed by our user space runner cannot be nested. This may be added in the future for the logging/eventing, but not for metrics.
 
 ##### RingBuffer
 
-`RingBuffer` is a generic map type which traditionally allows for temporary storage of many arbitrary data types. This allows the kernel or user space program to feed data into them, which can be read out in order from the other. In the case of `ebpfctl` the direction will be `kernel -> user`. In order to be able to generically handle this data however, we have imposed a restriction that only one type of data may be stored in the RingBuffer. This may change in the future.
+`RingBuffer` is a generic map type which traditionally allows for temporary storage of many arbitrary data types. This allows the kernel or user space program to feed data into them, which can be read out in order from the other. In the case of `bee` the direction will be `kernel -> user`. In order to be able to generically handle this data however, we have imposed a restriction that only one type of data may be stored in the RingBuffer. This may change in the future.
 
 In order to specify the type of data to be stored in the RingBuffer, it can be added to the `BPF` map definition. Typically it is not valid to store the type in a `RingBuffer` map definition, as there can be multiple types, but in this case it allows us to properly parse the data, and that type never makes it into the kernel map definition.
 ```C
@@ -55,13 +55,13 @@ Nothing specific has been added on top of the BPF programs/functions themselves
 
 ### Output Formats
 
-Part of what makes `ebpfctl` so special, as mentioned above, is that it allows us to write `eBPF` probes with 0 user space code. In fact it allows for easy translation of kernel data and events into metrics and logging. As mentioned above this is accomplished through the use of special conventions and keywords. Before reading this section, we recommend reading the [conventions](#BPF-conventions) above for a brief overview.
+Part of what makes `bee` so special, as mentioned above, is that it allows us to write `eBPF` probes with 0 user space code. In fact it allows for easy translation of kernel data and events into metrics and logging. As mentioned above this is accomplished through the use of special conventions and keywords. Before reading this section, we recommend reading the [conventions](#BPF-conventions) above for a brief overview.
 
 These special conventions and keywords come in the form of additional kernel code additions, some in section names, and some to the code itself. Let's begin with the section names.
 
-Maps in `BPF` programs are defined using the `SEC(".maps")` keyword. When running using the `ebpfctl` runner, extra suffixes can be added to describe how this data should be handled. These can be roughly broken down into 2 behaviors, metrics and logging. Metrics turns the data into prometheus metrics which can be consumed by any standard prometheus deployments. And logging which emits structured json logs with the provided data, and can be consumed by any structured logging applications.
+Maps in `BPF` programs are defined using the `SEC(".maps")` keyword. When running using the `bee` runner, extra suffixes can be added to describe how this data should be handled. These can be roughly broken down into 2 behaviors, metrics and logging. Metrics turns the data into prometheus metrics which can be consumed by any standard prometheus deployments. And logging which emits structured json logs with the provided data, and can be consumed by any structured logging applications.
 
-The second convention we have added is a set of `typedef`s which describe to our runner how the underlying type is meant to be processesd after it leaves the kernel. These are stored in a file called `solo_types.h` and are made available automatically when building with `ebpfctl`. Some examples include:
+The second convention we have added is a set of `typedef`s which describe to our runner how the underlying type is meant to be processesd after it leaves the kernel. These are stored in a file called `solo_types.h` and are made available automatically when building with `bee`. Some examples include:
 ```C
 // A basic ipv4 address represented as a u32
 typedef u32 ipv4_addr;
@@ -118,11 +118,11 @@ This one differs slightly from the `RingBuffer` example above in a couple import
 
 #### Metrics
 
-Potentially even more powerful than the logging features of the `ebpfctl` runner are it's metrics capabilities. As opposed to the logging feature, the metrics feature allows for creation and export of generic metrics + labels from `eBPF` probes. A couple simple, yet powerful, examples of this functionality are in the `examples` folder. `activeconn` keeps track of all active tcpv4 connections in a gauge with source/dest IP as the metric labels. The `tcpconnect` example does something similar, but it increments a counter for each new connection, rather than maintaining all active.
+Potentially even more powerful than the logging features of the `bee` runner are it's metrics capabilities. As opposed to the logging feature, the metrics feature allows for creation and export of generic metrics + labels from `eBPF` probes. A couple simple, yet powerful, examples of this functionality are in the `examples` folder. `activeconn` keeps track of all active tcpv4 connections in a gauge with source/dest IP as the metric labels. The `tcpconnect` example does something similar, but it increments a counter for each new connection, rather than maintaining all active.
 
 ##### Counter
 
-Currently there are 2 ways to use a gauge with `ebpfctl`. One with a `HashMap` and one with a `RingBuffer`.
+Currently there are 2 ways to use a gauge with `bee`. One with a `HashMap` and one with a `RingBuffer`.
 
 An example of the both the `RingBuffer` counter and `HashMap` counter exist in the `examples/tcpconnect` folder. The program tracks the number of TCP connections using both map types to illustrate their use. We do not recommend saving the same value two seperate ways.
 
@@ -147,26 +147,26 @@ As we can see the number of connections are being tracked both from our `HashMap
 
 ### Using our install script
 ```bash
-curl -sL https://run.solo.io/ebpfctl/install | sh
+curl -sL https://run.solo.io/bee/install | sh
 ```
 
 ### Using go
 ```bash
 # This will install directly to the configured GOBIN
-go install github.com/solo-io/ebpf/ebpfctl
+go install github.com/solo-io/bumblebee/bee
 ```
 
 #### Other options
 
-You can also navigate to the releases page [here](https://github.com/solo-io/eBPF/releases/) for more versions/information.
+You can also navigate to the releases page [here](https://github.com/solo-io/bumblebee/releases/) for more versions/information.
 
 ## Contributing
 
 Developing `eBPF` does not require a linux machine, however running the probes does. `eBPF` itself is a linux kernel technology, therefore any actual `BPF` programs must run in the linux kernel. We are working on an OSX development path, but it has not been completed as of yet.
 
 We recommend doing `eBPF` development on a linux machine. Do not fret however if you don't have a native Linux desktop, neither do we. Using `vscode` and GCP allows for a seamless near native development experience. See the following [article](https://safwene-benaich.medium.com/developing-on-remote-vm-via-vscode-using-google-clouds-iap-6b6549f9270c) for more detail. The article details the steps on a Windows machine, but they should be nearly identical on a Mac. 
 
-Also worh noting , `ebpfctl` does not currently support Arm architectures (coming soon). However, the above development trick should alleviate that issue in the short-term.
+Also worh noting , `bee` does not currently support Arm architectures (coming soon). However, the above development trick should alleviate that issue in the short-term.
 
 ### Repo Structure
 
@@ -175,8 +175,8 @@ The following is a brief overview of the internal code structure
 ```.
 ├── builder # Dockerfile and scripts related to our eBPF build container
 ├── ci # Scripts and helpers for CI
-├── ebpfctl # main.go file for ebpfctl, majority of code is in pkg
-├── examples # Variety of example eBPF programs to be run with ebpfctl
+├── bee # main.go file for bee, majority of code is in pkg
+├── examples # Variety of example eBPF programs to be run with bee
 ├── pkg # Primary code directory
 └── spec # Contains information related to eBPF OCI Spec
 ```

TUTORIAL.md

@@ -2,11 +2,11 @@
 
 ## Introduction
 
-Let's get started writing our first `eBPF` probe. This is super simple using the interactive `ebpfctl init` command. But first let's create a quick workspace directory using `mkdir ebpf-test && cd ebpf-test`.
+Let's get started writing our first `eBPF` probe. This is super simple using the interactive `bee init` command. But first let's create a quick workspace directory using `mkdir ebpf-test && cd ebpf-test`.
 
-Now let's run `ebpfctl init`!
+Now let's run `bee init`!
 
-## ebpfctl 
+## bee 
 
 The first option you will be confronted with is the language with which you will develop your probe. Currently only `C` is supported, but support for `Rust` is planned as well.
 ```bash
@@ -21,7 +21,7 @@ Next you will be asked for the type of global map you would like to use. Maps ar
   ▸ HashMap
 ```
 
-After deciding on a map type, you will be asked to decide on an output format. This step is the first that gets into the detail and magic of `ebpfctl`. Normally developing `eBPF` applications requires writing user space, and kernel space code. However, with `ebpfctl` you only need to develop the kernel space code, and then `ebpfctl` can automatically handle and output the data in your specified format. The 2 main output types available currently are: `stats`, and `print`. More information on these can be found in the [output formats](#Output-Formats) section below. We will be choosing `print` as a simple example.
+After deciding on a map type, you will be asked to decide on an output format. This step is the first that gets into the detail and magic of `bee`. Normally developing `eBPF` applications requires writing user space, and kernel space code. However, with `bee` you only need to develop the kernel space code, and then `bee` can automatically handle and output the data in your specified format. The 2 main output types available currently are: `stats`, and `print`. More information on these can be found in the [output formats](#Output-Formats) section below. We will be choosing `print` as a simple example.
 
 ```bash
 ? What type of output would you like from your map: 

ebpfctl/main.go → bee/main.go

@@ -3,14 +3,14 @@ package main
 import (
 	"log"
 
-	"github.com/solo-io/ebpf/pkg/cli"
+	"github.com/solo-io/bumblebee/pkg/cli"
 	"oras.land/oras-go/pkg/context"
 )
 
 func main() {
 	// Use context with discarded logrus logger so we don't fill our logs unecessarily
 	ctx := context.Background()
-	if err := cli.EbpfCtl().ExecuteContext(ctx); err != nil {
+	if err := cli.Bee().ExecuteContext(ctx); err != nil {
 		log.Fatalf("exiting: %s", err)
 	}
 }

ci/release_assets.go

@@ -11,12 +11,12 @@ func main() {
 
 	assets := []githubutils.ReleaseAssetSpec{
 		{
-			Name:       "ebpfctl-linux-amd64",
+			Name:       "bee-linux-amd64",
 			ParentPath: buildDir,
 			UploadSHA:  true,
 		},
 		{
-			Name:       "ebpfctl-linux-arm64",
+			Name:       "bee-linux-arm64",
 			ParentPath: buildDir,
 			UploadSHA:  true,
 		},

go.mod

@@ -1,4 +1,4 @@
-module github.com/solo-io/ebpf
+module github.com/solo-io/bumblebee
 
 go 1.17
 

install_cli.sh

@@ -9,7 +9,7 @@ elif [ -x "$(command -v python)" ]; then
 elif [ -x "$(command -v python2)" ]; then
   alias any_python='python2'    
 else
-  echo Python 2 or 3 is required to install ebpfctl
+  echo Python 2 or 3 is required to install bee
   exit 1
 fi
 
@@ -29,11 +29,11 @@ fi
 for ebpf_version in $EBPF_VERSIONS; do
 
 tmp=$(mktemp -d /tmp/ebpf.XXXXXX)
-filename="ebpfctl-${OS}-amd64"
-url="https://github.com/solo-io/ebpf/releases/download/${ebpf_version}/${filename}"
+filename="bee-${OS}-amd64"
+url="https://github.com/solo-io/bumblebee/releases/download/${ebpf_version}/${filename}"
 
 if curl -f ${url} >/dev/null 2>&1; then
-  echo "Attempting to download ebpfctl version ${ebpf_version}"
+  echo "Attempting to download bee version ${ebpf_version}"
 else
   continue
 fi
@@ -57,22 +57,22 @@ fi
 (
   cd "$HOME"
   mkdir -p ".ebpf/bin"
-  mv "${tmp}/${filename}" ".ebpf/bin/ebpfctl"
-  chmod +x ".ebpf/bin/ebpfctl"
+  mv "${tmp}/${filename}" ".ebpf/bin/bee"
+  chmod +x ".ebpf/bin/bee"
 )
 
 rm -r "$tmp"
 
-echo "ebpfctl was successfully installed 🎉"
+echo "bee was successfully installed 🎉"
 echo ""
 echo "Add the eBPF CLI to your path with:"
 echo "  export PATH=\$HOME/.ebpf/bin:\$PATH"
 echo ""
 echo "Now run:"
-echo "  ebpfctl init     # Initialize simple eBPF program to run with ebpfctl"
+echo "  bee init     # Initialize simple eBPF program to run with bee"
 echo "Please see visit the Gloo Mesh website for more info:  https://www.solo.io/products/ebpf/"
 exit 0
 done
 
-echo "No versions of ebpfctl found."
+echo "No versions of bee found."
 exit 1