We would love to hear from you! Here are some places you can find us.
Our mailing list is metallb-users@googlegroups.com. It’s for discussions around MetalLB usage, community support, and developer discussion (although for the latter we mostly use GitHub directly).
For a more interactive experience, we have the #metallb slack channel on k8s.slack.com. If you’re not already logged into the Kubernetes slack organization, you’ll need to request an invite before you can join.
Development of MetalLB is discussed in the #metallb-dev slack channel .
Use the GitHub issue tracker to file bugs and features request. If you need support, please send your questions to the metallb-users mailing list rather than filing a GitHub issue.
We welcome contributions to MetalLB! Here’s some information to get you started.
This project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.
Before you make significant code changes, please consider opening a pull
request with a proposed design in the design/ directory. That should
reduce the amount of time required for code review. If you don’t have a full
design proposal ready, feel free to open an issue to discuss what you would
like to do.
All submissions require review. We use GitHub pull requests for this purpose. Consult GitHub Help for more information on using pull requests.
By contributing to this project you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution. See the DCO file for details.
MetalLB’s code is divided between a number of binaries, and some
supporting libraries. The libraries live in the internal directory,
and each binary has its own top-level directory. Here’s what we
currently have, relative to the top-level directory:
controller is the cluster-wide MetalLB controller, in charge of
IP assignment.speaker is the per-node daemon that advertises services with
assigned IPs using various advertising strategies.internal/k8s contains the bowels of the logic to talk to the
Kubernetes apiserver to get and modify service information. It
allows most of the rest of the MetalLB code to be ignorant of the
Kubernetes client library, other than the objects (Service,
ConfigMap…) that they manipulate.internal/config parses and validates the MetalLB configmap.internal/allocator is the IP address manager. Given pools from the
MetalLB configmap, it can allocate addresses on demand.internal/bgp/native is a very stripped down implementation of BGP. It
speaks just enough of the protocol to keep peering sessions up, and
to push routes to the peer.internal/bgp/frr contains the code for translating the MetalLB configuration
to the FRR configuration that is applied to the FRR container, when running
MetalLB in FRR mode.internal/layer2 is an implementation of an ARP and NDP responder.internal/logging is a logging shim that redirects both
Kubernetes’s klog and Go’s standard library log output to
go-kit’s structured logger, which is what MetalLB itself uses for
logging.internal/version just burns version numbers and git commit
information into compiled binaries, so that MetalLB can print its
build information.In addition to code, there’s deployment configuration and documentation:
config/manifests contains a variety of Kubernetes manifests. The most
important one is config/manifests/metallb-native.yaml, which specifies how to
deploy MetalLB onto a cluster.website contains the website for MetalLB. The website/content
subdirectory is where all the pages live, in Markdown format.To develop MetalLB, you’ll need a couple of pieces of software:
go
tool)NOTE: The development environment was tested with kind
v0.9.0. Older versions may not work since there have been breaking changes between minor versions.
Start by fetching the MetalLB repository, with git clone
https://github.com/metallb/metallb.
From there, you can use Invoke to build Docker images, push them to
registries, and so forth. inv -l lists the available tasks.
To build and deploy MetalLB to a local development environment using a kind
cluster, run inv dev-env.
When you’re developing, running components at the command line and having them attach to a cluster might be more convenient than redeploying them to a cluster over and over.
For the controller, the -kubeconfig and -namespace command-line flags
are needed. Speakers need those and -node-name.
For example:
metallb$ go run ./controller/main.go ./controller/service.go -namespace metallb-system -kubeconfig $KUBECONFIG
metallb$ go run ./speaker/main.go ./speaker/*controller.go -namespace metallb-system -kubeconfig $KUBECONFIG -node-name node0
For development, fork
the github repository, and add
your fork as a remote in $GOPATH/src/go.universe.tf/metallb, with
git remote add fork git@github.com:<your-github-user>/metallb.git.
The following are our commit message guidelines:
When adding a new feature, or modifying a current one, consider adding a new test
to the test suite located in /e2etest.
Each feature should come with enough unit test / end to end coverage to make
us confident of the change.
The website at https://metallb.universe.tf is pinned to the latest released version, so that users who don’t care about ongoing development see documentation that is consistent with the released code.
However, there is a version of the website synced to the latest main
branch
at
https://main–metallb.netlify.com. Similarly,
every branch has a published website at <branch
name>--metallb.netlify.com. So if you want to view the documentation
for the 0.2 version, regardless of what the currently released version
is, you can
visit
https://v0.2–metallb.netlify.com.
When editing the website, you can preview your changes locally by
installing Hugo and running hugo server from
the website directory.
For information about the current maintainers of MetalLB, see the maintainers page.