Preface
Having contributed to a bunch of other projects like hyperswitch and kanidm I have been getting a hang of jumping into large code bases and only consider parts that were required to solve a particular issue. This time around, I had my eyes on the CNCF mentorship (term-1 2024) and knew that to make my chances higher I had to contribute to some respective project.
Having had experience with observability frameworks and how they work internally, I figured my best shot would be with Jaeger. To once who don't know Jaeger, Jaeger is an observability framework initially built by Uber for observability into their distributed systems. Previously Jaeger used to have components that were unique to themselves but worked with the open telemetry (otel) standard. But the direction Jaeger has been going these days, they seem to be packaging existing otel components with ease of developer use in mind.
Finding the right issue:
Any good first contribution always starts with finding the right issue to solve. When reaching out to the maintainer, I get the classic cold response :
Maintainer: Search for issues tagged with
good first issue[insert GitHub issues link with filter] ordifficulty:easy[insert GitHub issues link with filter]
This is understandable as the open source maintainer workload is high as is, and I followed those exact links. But my requirements to find good issues were different, in these ways :
- I wanted an issue that required me to work with their backend
- Was not under heavy discussion from other contributors (Towards the CNCF mentorship time this is an actual concern)
- Was doable within the next 2-3 weeks (because the CNCF submission date was looming around)
The issue that fit the bill was Allowing uploading of OTLP traces in UI
Due diligence
After finding the right issues and commenting that I was working on them, It was time to do my due diligence and understand what this issue was. It seemed fairly simple, people wanted to upload not only the Jaeger type trace but also OTLP type trace in the frontend. The first resource I came across was OTLP to Jaeger protocol transformation
From there it was clear that OTLP and Jaeger-type trace are similar but not the same. Further discussion with the maintainer also helped to clarify that, unlike other uploading functions, we don't want to persist the traces uploaded on this page. This page was only used for the comparison of traces. From here it was time for me to set up my system that I could test and also to collect traces that I could test with.
Having had experience with observability frameworks collecting traces was simple. Furthermore, reading the CONTRIBUTING.md and similar documents always helps with setup.
Solution and review cycles
I did not want to write large amounts of front-end logic to make this work. So I decided to write an endpoint in the backend that converts OTLP trace to Jaeger traces and the frontend already could understand Jaeger traces. This solution was along the lines the maintainer expected. So I got to coding. To say this was easy would be wrong.
I spent large amounts of time in the otel-col-contrib repo that has a bunch of translators (including OTLP to Jaeger). But getting it to fit into the Jaeger code base was a challenge of its own. From checking for valid traces to formatting the Jaeger output from an external library to fit into the existing response structure, It was a journey. It was a LARGE number of reviews and changes. And to also include fixtures and tests for the API endpoint was a new experience. I learnt how testify works and how testing is done on API endpoints.
Equally so, the frontend was very fun. Frontend for Jaeger uses redux for state management (Not even simple redux, they use redux actions). Redux actions in how I would put it, is a syntactic wrapper on top of redux to reduce repetition of code. Also to mention, I got quite comfortable with jest, a testing framework for frontend.
Not to mention, redux actions hate async stuff in its critical path and an API call is async. this required me to mess with thunk middlewares. Thunk middleware helps with delaying your action based on your payload into your action.
Result
Sadly, I did not get selected (I'm being direct unlike companies) for the Jaeger project in CNCF. Nevertheless, it was a good learning experience with this small PR in the project. I did follow up with the mentors as to why I wasn't selected and the response was that my proposal lacked details. So concerning CNCF the mentorship a contribution is a hard requirement and a good proposal is what gets you in.