)
Participate. It’s a simple word, but has a lot of meaning packed in.
At a recent virtual OpenDev event, Jonathan Bryce, executive director of the OpenStack Foundation (OSF) told attendees this is of the most critical things to do once you join an open source community. He encouraged participants to think broadly and remember that collaboration is built by people who are actively engaged and participating by sharing their knowledge and experiences so they can learn from each other.
This is exactly what some North Dakota State University students recently did for the OpenStack Ussuri release.
North Dakota State University has a capstone class every spring that matches small groups of students with open source projects. This spring was the second time OpenStack has participated in this program. Last year, the students were involved in StoryBoard, specifically, enhancing the migrations scripts that the community uses to move people off of Launchpad to StoryBoard.
This year, the OpenStack community had four students helping to add support for configuring TLS ciphers and protocols on Octavia load balancers. Along with Michael Johnson, and Adam Harwell, students were mentored through their semester helping them learn not only about Octavia, but about OpenStack, and open source. They had real world experience communicating with a global open source community, responding to comments on patches they pushed, and managing their time to accomplish what they set out to before the end of their semester. With their hard work, they landed TLS cipher and protocol support before the end of the Ussuri release and it became a large part of the promotion and marketing around the release.
I interviewed each of participants to learn how they got started and what their takeaways were. Below are responses from Dawson Coleman, a recent graduate of North Dakota State University.
What was the hardest part about getting started?
I thought about just writing “DevStack” here and moving on to the next question. While that would obviously be hyperbolic, struggling with DevStack was the defining theme of my start with OpenStack development.
The thing that was hardest for me was what were some of the less-than-obvious pitfalls. For example: there’s currently a bug in neutron where if the system is restarted (a virtual machine in my case), all the network interfaces break. The fun part of this is unless you explicitly check all your network interfaces and know what to look for, you would have no idea this happened, and in my case I didn’t notice that anything had gone wrong until load balancer creation failed inexplicably.
From a learning/onboarding standpoint, it’s not particularly hard to deal with an issue like this: just don’t shut down your VM. Getting to the point where you’re aware of that fact, however, isn’t always a pleasant process. It’s those little things that you might have to learn the hard way that I think were the hardest part about starting out.
What could have made the getting started process easier?
While it would be easy for me to sit here and talk about bugs and say “make it not do that”, I recognize that maintaining something like DevStack isn’t simple and spending time on maintenance isn’t free. I think something that’s easy to miss as a junior dev is that in some cases it’s actually more efficient from a productivity standpoint to just leave quirks as they are, even if the workarounds aren’t always convenient, since all the serious users of your tool will eventually learn how to deal with it.
That being said, I think It would be cool if there was a “common problems” section or something equivalent mentioned in the getting started guide for DevStack, even if it was just links to bugs reports or something of a similar nature.
Of course, I couldn’t mention my struggles with DevStack without also mentioning all the great help I received in the #openstack-lbaas IRC channel. At first I was really worried about interrupting others with my questions or being too much of a noob, but I found that everyone I interacted with was very understanding and helpful. I think if I had realized this earlier I could have solved some of my issues even faster.
What was the biggest benefit you got out of your involvement? (hard or soft skills, connections, etc)
All things considered, I think the biggest benefit was all the different aspects of the development process I got to experience and being able to see how all the different facets of that process come together at the end of the day. This wasn’t some throwaway demo for a class presentation, this is a real product that will be run on production servers. To have the opportunity to participate in working on a project like this and see how all the parts fit together was something truly special, and it’s definitely one of the highlights of my college experience. If I had to pick out some highlights, though, these are what they would be:
Outside of one tiny commit to the Skia graphics library, working on Octavia was my first experience participating in any open source project. Octavia was a great introduction to participating in open source development.
Python is everywhere nowadays. I wasn’t particularly well versed in the language coming into the project, but Octavia gave me a taste of a production Python codebase, being able to work on multiple areas such as REST APIs, database management, and unit testing.
Through the process of being introduced to OpenStack’s workflow I also got the opportunity to work with some new tools like IRC chat and Gerrit code review. Experience with these tools is applicable to tons of projects.
The opportunity to participate in code reviews and have technical discussions was a great experience.
Even though they play a comparatively minor role, I found all the various tools that were used to automate processes like documentation and release note generation to be fascinating.
What advice do you have for students who want to get started with open source?
I think the biggest key to success in joining any project would be to start with a willingness to learn, and I would emphasize that a willingness to learn is just as important when it comes to a project’s development process as the code itself. Being considerate, respectful of peoples’ time, and willing to communicate goes a long way. If you run into roadblocks as a newcomer, you definitely want to make sure to do your due diligence in solving problems yourself (making sure to read relevant documentation and resources), but asking questions can help the project as well as yourself. If you run into issues that the project hasn’t documented yet, you might have an opportunity to help document bugs.
Stepping into a new group of people can be intimidating at first, but as long as you make an honest effort to coexist with others it’s hard to go wrong. As with introducing yourself to any new group of people, there will always be that element of uncertainty, but I think it’s a risk that’s worth taking, and one that looks way scarier than it actually is. The OpenStack community I have found to be nothing but friendly and helpful. One phrase that I was told repeatedly during the onboarding process was “don’t be shy”, and I think that sums it all up pretty well.
What made you interested in OpenStack as a project, as opposed to some of the other options?
I was actually introduced to OpenStack when I worked at NDSU’s research computing department, although at the time we were only using it to manage VMs. From there I had a general idea of what OpenStack was, and after seeing just how widespread it was actually used I thought working on OpenStack would be a great opportunity. I’ve also found cloud infrastructure to be an interesting field, and I figured it’s a growing market.
The thing that was unique about the OpenStack Octavia project was the open-source aspect. I was aware of this going in, but I think I really only appreciated the benefits of it in hindsight. Almost all of the other choices were proprietary projects that would belong to their respective companies afterwards. Now, don’t get me wrong–some of those companies were working on some neat stuff! However, at the same time, it’s doubtful that the students who worked on those projects will ever see their code again.
The transparency enabled by open source, on the other hand, opens up a lot more opportunities for me to revisit my contributions after the fact. If I ever want to show explicit examples of what I worked on, I have that. My commits are even linked to my GitHub profile! And if for some reason I eventually wanted to reuse that code for something else, I could. In that sense, even though the code belongs to OpenStack, I can still have some feeling of “ownership” in that I still have a lot of accessibility to the code under the Apache license. Now, even if the code I wrote most likely doesn’t have realistic applications outside of Octavia, it’s cool to be able to have something to show for your work after everything is all said and done.
What did you like most about your involvement with the OpenStack Octavia team? What did you contribute to the Ussuri release?
What contributed the most to making my involvement enjoyable was the atmosphere in the community. We were fortunate to be able to work closely with current Octavia PTL Michael Johnson throughout the entire process, and the weekly video meetings we had as a team were pivotal in answering our questions and keeping us on track towards our goals. I think we owe a lot of what we achieved to him as well as the rest of the Octavia community.
My role on the NDSU Octavia project was doing a majority of the back-end development. In Ussuri, I implemented TLS cipher selection in Octavia. This is a big step forward, as before you could create a TLS load balancer but there was no standard way of even knowing what ciphers would be accepted. In Ussuri this has been fleshed out into its own configuration field, so now it’s straightforward for operators to know and specify exactly what ciphers their load balancers will use.
Due to time constraints, we were only able to get cipher configuration for inbound connections done for Ussuri. This is only one part of the new set of TLS configuration options, which will include configuration of both TLS ciphers and versions for incoming connections and back-end re-encryption, as well as a cipher blacklist and a minimum TLS version option. These features have been merged and will be available as part of the Victoria release.
- 10 Reasons to Back Upstream Open Source Contributions - January 2, 2024
- University Program – Outreachy - November 19, 2023
- October 2023 PTG | Recap - November 15, 2023
Ghanshyam Mann
Sunny Cai
Helena Spease
