+1 (669) 231-3838 or +1 (800) 930-5144

Getting Started Upstream in ODL

By Allan Clarke and Anil Vishnoi

 

 

Getting started as an upstream contributor to OpenDaylight is not easy. The controller ecosystem is big, there are many projects, and there are millions of lines of code. What is a new ODL developer to do? Here is some pragmatic advice on where to begin to become an active contributor.

Fix Bugs

One of the easiest ways to get to know a code base is to start fixing bugs. Peruse the ODL bugs list on Bugzilla, say with the NETCONF project. You want to find bugs that aren’t likely being worked on and are of limited scope (to match your limited understanding of the project). Ideally bugs will have an owner assigned to indicate that they are actively being worked on, but it is not always a great indicator. In particular, someone may run across a bug, file a report, then jump into fixing it—and forget to assign it to themselves. This is most likely with the project contributors, so figure out who are the project contributors and look at the date of the report. If it was a project contributor and a newish date, then that bug might be being worked on. You should read through the report and try to decide how much domain knowledge is needed—as a newbie, smaller is better.

Once you have selected a bug to work on, click on the “take” link. Also add a comment to the bug. If someone already is working on it, they should get a notice and respond. You can also try the ODL mailing lists and give notice there. You mainly want to avoid duplicate work, of course.

Review Patches

Reviewing patches is a great way to contribute. You can access patches via Gerrit, and we’ll use the NETCONF patches as an example. Doing code reviews is a great way to not only see existing code but also to interact with other developers.

  • If you have some domain expertise and know the code, you can review the functionality that is being pushed.
  • If you have neither of these, you can do the review based on Java best practices and good software engineering practice.

Address Technical Debt

ODL uses Sonar for analytics of the upstream project. Here is an example for the NETCONF issues. Note that the ODL project has coding conventions, and the Sonar Qube has some best practices. This list shows violations that should be addressed. As a newbie, you can work on these with little domain knowledge required. You can also see that the code coverage varies for the NETCONF coverage, so adding NETCONF unit tests to boost the coverage in the weakest areas would be very helpful.

Sonar has a lot of interesting metrics. You can explore some of them starting here including coverage, tech debt, etc. If you look at the Sonar dashboard, it will point out a lot of available work that does not require a large span of time to invest. Doing some of this work is a great step towards getting your first patch submitted.

Follow Best Practices

With well over a million lines of code and many contributors from many companies, the ODL project has quite a girth. To manage the code entropy, ODL has some best practices that you should become familiar with. These cover a diverse set of topics, including coding practices, debugging, project setup and workflow. We strongly recommend that you carefully read these. They will save you a lot of time and will pay back your investment quickly. They will help you skate through code reviews. These practices are really time-tested advice from all the ODL developers, so don’t ignore them.

Support Attribution

Attribution is an important insight into most if not all open source projects. Attribution allows stakeholders to see who is contributing what, from the individual up through sponsoring companies. It allows both a historical and current view of the project. You can see an example of why attribution is illuminating here. You need to sign up for an ODL account, and a part of that process will be to associate yourself with a company (if applicable). You can also see breakdowns by authors on the ODL Spectrometer.

That’s all for now. Happy trails, newbie.

Watch for Allan’s blog next week where he will share his Top 10 learnings as a new developer contributing to ODL.

Welcome to Lumina Networks

Today Lumina Networks is launching through our acquisition of Brocade’s SDN Controller product family and the joining of its talented development and services engineers. We are truly thrilled for this new chapter and opportunity to work with you.

Lumina is dedicated to the advancement of open software networks that give providers control over how they implement their ideas and priorities for change. We believe our job is to be the catalyst to bring open software networking out of the lab and into live networks, and we have the products and expertise to help our customers do just that.

As Lumina Networks, we will continue to provide the industry-leading Lumina SDN Controller, powered by OpenDaylightTM (ODL) along with our optional controller-based applications. As you may know, this solution offers a common, open platform for developers, giving providers direct control over their SDN development and implementation, thus eliminating vendor lock-in. What you may not realize is how widely deployed the ODL Controller is today, now supporting over 1 billion users worldwide.

In addition, we will also offer Lumina NetDev Services for organizations that wish to accelerate the implementation of their open software network and want to expand the skill set of their network engineering and operations team through hands-on experience. Our NetDev Services team of experts works with customers to jointly develop production systems using Agile methods to prototype and speed through proof-of-concept and pilot phases. The team’s expertise and willingness to work spans open source, Lumina products and any third-party products needed to achieve multi-vendor interworking.

This is a particularly gratifying day for me, having spent my last three years at Brocade, working alongside this outstanding team and developing what we believe to be a unique set of products and services. Learn more about why providers around the world are working with Lumina now and the principles we are committed to following to bring open software out of the lab and into the live network.

If this resonates with you, and you have a software networking project in the lab that you are ready to move to the live network, please reach out. Join our movement and get out of the lab today!

 

Why Lumina Networks? Why Now?

The elusive promise of open software networking

Software promised to eat the world, but networking has proved a little harder to digest. While applications and data centers have experienced dramatic and visible change, the network itself has remained remarkably stubborn to virtualization and automation.

Network vendors sold magic pills to grow superpowers, matching hyperscale providers in skills, technology and speed. Placebos of course, take time to be discovered and the promised agility remained elusive.

Meanwhile, a quiet revolution brewed at providers. In backrooms and labs, on weekends and in free moments, passionate, committed renegades have been working on the technology to bring transformational change to their networks. These teams realize that change has to come from within and cannot be outsourced. No magic pill can replace the hard work that all lasting change requires. Their call-to-arms is open source, virtualization, and automation. They take inspiration from the methods of hyperscale providers but must apply technology pragmatically to both their new and old infrastructure.

Escape velocity

In these labs, all of the right ingredients—open source software, agile technologies, white boxes, abstraction models and programming skills—are now proving themselves in performance and in features.  So what is stopping these solutions from escaping the lab and being deployed in production networks? I believe the missing ingredient is a catalyst.

By definition, a catalyst causes ingredients to react, to bond, and to change the form of elements around them. Such a catalyst is needed to bring the new into the existing network, to integrate with what is there, and to bond the benefits from the greenfield to the brownfield. And perhaps most importantly, to furnish expertise, support and enablement to the internal teams charged with making it all happen.

This change from within has reached a critical moment. Providers must now choose technology differentiation from within, or wait for the market to deliver turn-key solutions. If differentiating now carries risk, waiting to be usurped by others surely carries more. Those who think competitively realize that turn-key is a zero-sum game. Everyone gets essentially the same solution at the same time, in a world where time is now the greatest competitive force setting apart the winners from the losers. Those who build their own solutions—using off-the-shelf components married to unique in-house developed functionality—build-in the agility and options for difference that are necessary to stay ahead. Few would argue that differentiation in the digital world demands control of your own destiny in how you develop and deploy technology.

Changing together with each other

At the center of every transformational change are heroes. These heroes form one part of the change, their network and their organization the other. Yet, these heroes often have to work in conflict with their organizations that have ingrained ways of working.

It’s not as if these heroes have not been offered ‘help’ along the way. Traditional networking vendors and integrators have fallen over themselves to sign providers up for transformational change. But the results have been lackluster, at best.

When you put the fox in charge of the hen house, it eats time and money, then leaves a trail of legacy software and hardware behind. No, the challenge is that the change must come from within—meaning that providers must be responsible for their own journey and cannot simply outsource the work to the cheapest or most shiny bid that comes in from the outside. Maybe I’m being too hard on the fox. The reality in many cases is that the fox does want to change, does want to adapt but isn’t really in a position to affect change because, well, they still love to eat chickens.

As an alternative, many in the networking community have spent the last three years working out how to build software networks out of open components. The thinking is that if you can build your software network with open source, where the possibility to change vendors is always available, these vendors will continue to work extremely hard on your behalf, to stay at the top of their game, and to do what is best with you.

And so, I’ve come to believe that what heroes need is a catalyst that will work with them and their organization. Deliver projects with them is the big idea—not to them, or for them. Working together, from within, change is genuine and sustaining. It is shaped to specifics of the organization. I believe that with a catalyst, teams can achieve self-sufficiency and resolve the indigestion now afflicting their networks.

Being a part of the change

I am most fortunate to have formed, with a mighty team of similarly-minded challengers, our own company that we called Lumina Networks. As Lumina Networks, we are embracing the ethos of catalyst, a catalyst that works with our customers, our partners and our developer communities. We are focused on aiding transformational change in providers—without reservation or conflict from other considerations (e.g. hardware)—working with our customers to make change possible, one small advance in capability, one shift in mindset, one step at a time.

For the past three years, and as part of Brocade we’ve been able to learn much about execution in this new way of business. Our development engineers and NetDev Services team have been working closely with the world’s largest providers in building open technologies and integrating them into large, complex production networks. We’ve been there, in the room, working through the gnarly challenges of what it really takes to change networks. We’ve been there as customers consider what it means not only for their architectures and technology, but also for those who must operate the networks reliably, securely, at carrier scale, and for those who must figure out how all of this now works with the back office delivery systems.

We see the industry evolving quickly in how it collaborates through the vehicle of open source community to build the best of what’s possible. Providers know there’s much they must do together in developing technology, while using how they define and deliver services to stand out in the experiences they create.

Lumina Networks Principles

As we set out, we wanted a set of principles for Lumina Networks that guide us, and represent our “true north”. These principles are simple, yet they govern difficult decisions, balance tradeoffs and help us to avoid pitfalls.

  1. Open source first. Work with engineering communities to develop platforms that solve industry-wide problems.
  2. Pure open source network products. No forking from community code or proprietary extensions that create lock-in, packaged for specific use cases and ease-of-use, and commercially supported for reliability. To ensure 100% compatibility, we upstream our enhancements and fixes.
  3. Network products as swappable components. Open interfaces and software elements focused on a small, well-defined set of clear functions to provide ease-of-integration, based on standard models.
  4. Integration with third parties. Products readily combined with those from other companies, including the lengthy list of legacy technologies and interfaces now embedded deeply into provider networks. Meet the needs of today and tomorrow without needing to rip out of everything that providers have today.
  5. Platform approach. Components combined to create extensible solutions for infrastructure and customer services. Not only does a platform approach ease change in the future, it enables an incremental approach today to deliver immediate, achievable improvement.
  6. Designed for serviceability. Embracing the DevOps and Site Reliability Engineering movements, operations and support teams and their requirements are brought to the front of the design and development process. Networks shake off their past and deliver the holy grail of increased reliably in conjunction with increased agility.
  7. NetDev Services. Engineers leading the Agile development and deployment of new software technologies, both networking and operations software, must be willing and able to work in joint teams to pass on knowledge and skills, tools and practices that lead providers to self-sufficiency.
  8. Open business relationships. Licenses and contracts that define how vendors and providers work together must change so that developers have full ownership of their innovation, customers have full control over their priorities for change, and well-defined outcomes leave the flexibility to adjust in details with new learning of teams.

We see our job to be the catalyst in bringing open software out of the lab and into the live network. These are the principles that guide us in working with providers and in building the open software networks of the future.

If these principles resonate with you, and if you have a software networking project in the lab that you are ready to move to the live network, reach out. Join our movement and get out of the lab today!

Pin It on Pinterest