I wanted to make a good first impression when G-Research requested that we (the Open Source team) shepherd new functionality into OpenStack (the open source cloud infrastructure we use). I was a new contributor to OpenStack and I was motivated to demonstrate that open source could play a role in even the most secure environments.

Our goal was to enable SSL communication for OpenStack services, so that internal service communication could be secure. I began by asking the OpenStack deployment infrastructure service (Kolla) lead what the recommended approach would be. He referred us to the lead of the OpenStack networking service (Octavia), who offered a good approach. He suggested we first provide a proxy layer on each node that could perform SSL termination for all internal communication.

It seemed like a solid-enough solution, but we felt validated when other OpenStack contributors agreed. They had used this same approach to solve a similar problem for a previous company. It would be the fastest route to achieve secure communication immediately and then we could implement native SSL termination in each service using WSGI one at a time, removing them from behind the secure proxy server.

It took me about a month to build a proof-of-concept in Kolla Ansible. I was new to the OpenStack ecosystem and the learning curve was pretty steep. Working in a different timezone than the main devs meant I had to learn by trial and error. It turns out there are many layers of complexity in a cloud infrastructure.

When I presented this proof-of-concept to the OpenStack Kolla Ansible community, there was concern that this was an intermediate solution that had too many network hops, and would cause maintenance issues later. ‘Good enough’, it turned out, wasn’t good enough.

Even though my solution worked, and we had gotten input from some of the community, it hadn’t been vetted by the entire Kolla Ansible dev community. After polling the developer community (those who had shown up to the weekly meeting), slightly more sentiment leant towards not introducing a new proxy layer.

That was hard to hear. The proof-of-concept (POC) felt hard-earnt. I mean it did work, functioning reliably, despite being a bit kludgy and inelegant.

After my initial defensive reaction – lasting about half-an-hour – I remembered again what I was trying to do here. I wanted to be a helpful member of the community. I had come here with something I had created and the community had said they wanted something different. It was up to me to understand the reasons why and focus on how to make the code better.

So I’ve set off on a new path, service by service. l will contribute something useful for the OpenStack community. While my employer will benefit from this work, there is already strong interest from other companies for this feature. It’s really nice to feel like I’m contributing something to the public domain, which is a new feeling to have for a work project.

My last role was writing code for a company with a notoriously locked-down approach to its software. Changes were impossible to implement into the hairball it had running its database products. There was no transparency and kludgy “solutions” were the norm. Though it made the products quite finicky, the company was unconcerned, as it was more than happy to tack on a “consulting agreement” to each sales contract it signed.

In contrast, the OpenStack community polices itself on preventing backwards code (like mine had been!) from getting in. It’s one of the things that makes the experience special. The project team lead (PTL) for Kolla Ansible has been super responsive, supportive, and willing to carefully look at lots of infrastructure code, which takes impressive levels of focus.

The POC was a great learning experience and allowed me to quickly become steeped in the world of OpenStack, Ansible, and Jinja2. The lesson for me is to slow down and make sure to have full community buy-in before building features. It’s a new way for me to be useful. One that starts with listening and builds on community buy-in before ultimately delivering on promised functionality.