OpenStack Upstream Training
Tags: openstack
I grabbed one of the last tickets to the OpenStack Upstream Training that ran the weekend before the Atlanta OpenStack Summit.
I’ve used open source for longer than I care to remember, and I’ve even submitted a few patches along the way, but I’ve never become a member of a project. I felt a little under- and over-qualified simultaneously. How could I feel overqualified if I had never become a repeat contributor? I know how to program, but contribution is a lot more than programming. See if any of the phrases sound familiar:
- I just need to sit down and figure it out. (repeated weekly)
- I’m going to work on bug $X tomorrow. (repeated weekly)
- I hope I do this right, I don’t want to look stupid.
Here’s a hint: “I just need to sit down and figure it out” repeated more than once is code for “I don’t really want to do this” or “I have no idea where to start, and I could use a little guidance.” In my case, it was the latter.
The size and sophistication of OpenStack intimidated me. I’m no stranger to code review, continuous integration, and automated testing, but OpenStack is big. There are more hosts running or ready to run automated tests for OpenStack than we use to service our biggest application at $DAYJOB. (Check out the “Job Stats” graph on the Zuul Status Page to see a live count of hosts.)
My biggest problem was a people problem: I was convinced that while navigating the OpenStack build and review environment for the first time I’d make a mistake, and people would think I’m stupid. In retrospect, that was stupid of me. Of course I’d make mistakes, but the people and the processes exist to help us build a better product, accounting for the possibility of mistakes along the way. OpenStack doesn’t get built in large chunks of caffeine fueled code tossed over a wall. We build it one small, well reviewed, well tested patch at a time.
The OpenStack Upstream Training broke down into three major components:
- The Training Class
- The Design Summit
- The Mentoring
The Training Class
Scheduled in the two days prior to the Summit, we soaked in the technical and social processes of OpenStack, and we didn’t have time forget it all before the Summit began.
The bulk of our classroom training focused on the people and the social processes in open source, and specifically OpenStack. Behind every patch and every review comment there is a human being with hopes, goals, stress, problems, and dreams. We all want to build a great system, and we’re all constrained to 168 hours each week. The PTL that doesn’t respond to an email isn’t ignoring you on purpose, she’s drowning in email and constantly trying to dig out. Gerald Weinberg reminds us in his writing that “no matter how it looks, everyone is trying to be helpful.” We can never go wrong with empathy.
Even if you don’t attend Upstream Training, you should definitely read Communication Gaps and How to Close Them.
The Design Summit
Summits are more than just a traditional conference. Design discussions to shape the next release fill more than half of the week. Upstream students’ most important assignment for Summit week was to find and meet the team members that would review our chosen work.
“Introduce yourself, tell them what you’re interested in working on, and how much time you will commit each week. They are busy, they will love you.”
I met a large chunk of the Designate team, and I learned how little I know about running DNS at scale. That’s OK, though, I’ll learn more as I go, and the team will help along the way.
The Mentoring
The class followed by the summit made for an exhausting week. It would have been easy to fly home, sleep for a day, and get lost in $DAYJOB work for a week trying to catch up. “I’ll do some OpenStack work next week once I’ve caught up on home and work.”
Wrong. The habit of OpenStack contribution isn’t yet built, and taking a week off will destroy any momentum. The program includes weekly mentoring sessions to keep students moving forward. Loic set aside valuable time on Wednesdays and Saturdays to check in on students and keep them moving toward their goal, and it was vital for my success. I stayed up until 4:00 AM the night before my first mentoring session because I didn’t want to let him down, and I wasn’t happy with my progress thus far.
I now have one patch merged, one under review, and one in work. I’m also working on improving the automated testing for Designate, and I suspect I’ll work on documentation in coming months as well.
Should you attend?
You, too, should attend OpenStack Upstream Training if you feel capable but stuck when considering open source contribution. The training will give you the social and process knowledge to succeed, and the encouragement to keep moving forward until you build up your own momentum. It’s hard work, but it’s fun work.
The Upstream University training changed the trajectory of my career. I’ll forgive you for dismissing that as hyperbole since I’m still so early in the process, but I already feel addicted to the scale of OpenStack and the hum of hundreds of sharp developers and operators improving it one patch at a time.