Linux Foundation Mentorship '22 with OpenELB

Linux Foundation Mentorship '22 with OpenELB

Aug 7, 2022ยท

5 min read

Greetings Kubernauts ๐Ÿ˜„! I am extremely grateful to have had the opportunity to work on OpenELB to support BGP policies as part of the Linux Foundation Mentorship Programme '22 under the mentorship of Chauncey Jiang, Yunkang Ren, and Feynman Zhou. Read on to know more about my LFX '22 journey and its twist and turns.

Week 1

I had spent time getting familiar with the codebase before and during this timeframe. The pull requests which I made during this time frame helped to get my feet wet:

  • Update readme - #274
  • Add GitHub templates and Dependabot - #287

Week 2

I submitted a proposal as part of the LFX, some organizations don't require it, but I did it for my sake, to help understand the project better. This was my first time developing with Kubernetes and the entire system can get intimidating, a proposal helped me break it down into smaller problems. Later, the mentors communicated to me that they had a few ideas which were very much in sync with my proposal. This week was spent testing out pieces and ideas for the proposal along with suggestions from the mentors. Pull requests:

  • Improve logging - #278
  • Add a better context abstraction - #277

Week 3

OpenELB uses Kubebuilder and Kustomize for building CRDs. Since my proposal involved a lot of CRDs, I had to become familiar with these tools. With some understanding of the tooling I made a few pull requests to resolve a few bugs in layer2 mode:

  • Add CIDR range for NICs in layer2 - #282
  • Better EIP verification for layer2 mode - #281

Week 4

I continued learning more about the OpenELB codebase and brushing up on Linux networking fundamentals during this time frame. It's wonderful to see how good software like iptables and tons of other Linux networking CLI toolkits have stood the test of time. This week I tried to solidify some policy elements like DefinedSets and get them up and running to support GoBGP policy using CRDs. Work from this week:

  • feat(bgp): Add configuration for DefinedSets - #287

Week 5

The mentors came up with a new design idea which sounded much better and easier to use for the end-user. We decided that it was better to put the GoBGP policy configuration in the ConfigMap like coreDNS. This did lead to some changes of plans, after some thinking, reworking, and discussions, I came up with a PR where I added a basic scaffolding/framework to build upon for adding other GoBGP policy elements.:

  • feat(bgp): add GoBGP policy framework - #292

Week 6

#292 required a lot of improvements to be useful, I had integrated it with the BGP configuration controllers but I began to explore the possibility of working without controllers and CRDs altogether. This week was spent trying out different options to suit the new design proposal. Pull requests from this week (casual maintenance):

  • cleanup: minor changes to codebase - #294

Week 7-8

Earlier, OpenELB used controllers and CRDs to specify BGP configurations. The new PR I made (linked below) introduces a user-facing change so as to implement the new design proposal (refer #287 (review)). OpenELB users can now port their GoBGP configurations in TOML using a ConfigMap. Example ConfigMap to help understand:

apiVersion: v1
kind: ConfigMap
  name: openelb-bgp-configmap
  namespace: openelb-system
  gobgp.conf: |
      as = 50000
      port = 17900
      router-id = ""

            peer-as = 50001
            neighbor-address = ""

Currently pending is the work with pkg/speaker/peers.go to migrate metrics to use the GoBGP server. Pull request from this week:

  • Replace controllers and CRDs with ConfigMap - #302

Week 9

#302 brings a user-facing change which means it will stay as a proof-of-concept until a few other things are clarified, which may take longer than the LFX time frame. Therefore, this week, I decided to work on keeping compatibility with the CRDs and move only the BGP policy elements to a config map. This did bring some additional complexity which was handled #302 earlier and halted the Prometheus-related work in my branch, but yeah, you win some you lose some ๐Ÿค .

Week 10

#292 was the focus of this week. I added complete support for BGP policies. The method I used involved reading data from a config map and converting the data to the gRPC API types used by GoBGP. Unfortunately, the mentors hadn't expected such type of conversion to be necessary to resort to and found the diff too big to review. I then discussed and worked on prototyping a solution with help from the mentors (link - go playground). Here's the summary of the new options tried to implement the new design:

  • Parsing from GoBGP TOML config structs to GoBGP gRPC API structs (done in #292): Unfortunately, the amount of code change might have been a bit too big.
  • Parsing from BGP CRD types to GoBGP TOML config: In this option, we'll be using pkg/config of GoBGP to make all RPC requests and will replace all the bgpServer requests we make currently in OpenELB. This will be similar to #302 with the difference being that backward compatibility with BgpConf and BgpPeer will still be maintained.

Pull requests from this week:

  • feat(bgp): add method to configure BGP policies - #292
  • design(pkg/bgp): use GoBGP pkg/config for BgpConf RPC requests - #305 ๐Ÿ‘ˆ newest design

Week 11 - 12

The amount of code change for any method listed previously would amount to almost the same. For this reason, the mentors and I decided to stick to #292 because it was a working and mostly complete PR. I spent the remaining time addressing the review comments of the mentors and incorporating feedback.


It was awesome fun working on K8 controllers, CRDs, and a project which involved networking concepts. There were twists and turns along the way but somehow managed to consolidate everything and bring it to fruition. All the mentors were extremely helpful and responsive all along the way, and I truly thank them for putting in the time and effort for mentoring me to make this project happen ๐Ÿš€. See you later with new PRs and new updates ๐Ÿ˜. ๅ†่ง ๐Ÿ‘‹.