+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.

Service Providers Are Placing Big Bets on Open Source Software Networking – Should You?

The service provider market is undergoing earth-shaking changes. These changes impact the way that applications for consumers and business users are deployed in the network and cloud as well as the way that the underlying data transport networks are built.

At Lumina, we’ve had the chance to work with several large service providers on their software transformation initiatives and get an up-close look at what works and what doesn’t. Three factors are particularly favorable in setting up successful projects for frictionless progress from the lab through prototype and proof of concept and into the production network.

Top-Down Advantage

Our first observation is that top-down initiatives and leadership work better than bottom-up or “grass roots” approaches. The experience of AT&T strongly illustrates the advantage. While a few of the hyperscale cloud providers had already launched open source initiatives and projects, the first big move among the established service providers was AT&T’s Domain 2.0, led by John Donovan in 2013. Domain 2.0 was not a precise description of everything that AT&T wanted to do, but through that initiative, the leadership created an environment where transformative projects are embraced and resistance to change is pushed aside.

While lack of top down support is not a showstopper, it is extremely helpful to get past obstacles and overcome organizational resistance to change. If top-down support in your organization is lacking or weak, it is worth your effort to influence and educate your executives. In engaging executives focus on the business value of open software networking. The advantages of open source in software networks include eliminating lock-in and spurring innovation. As our CEO, Andrew Coward, wrote in his recent blog, Why Lumina Networks? Why Now?: “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.”

Although it may create a slower start, from what we have seen, taking the time to do early PoCs to onboard executive support so that they deeply attach to the value is time well worth spent. Sometimes a slow start is just what is needed to move fast.

Collaboration through Open Source

The second observation is that industry collaboration can work. I read an interesting comment by Radhika Venkatraman, senior vice president and CIO of network and technology at Verizon, in her interview with SDxCentral. She said, “We are trying to learn from the Facebooks and Googles about how they did this.” One of the best ways to collaborate with other thought leaders in the industry is to join forces within the developer community at open source projects. The Linux Foundation’s OpenDaylight Project includes strong participation from both the vendor community and global service providers including AT&T, Alibaba Group, Baidu, China Mobile, Comcast and Tencent. Tencent, for one, has over 500 million subscribers that utilize their OpenDaylight infrastructure, and they are contributing back to the community as are many others.

A great recent example of industry collaboration is the newly announced ONAP (Open Network Automation Platform) project. Here, the origins of the project have roots in work done by AT&T, China Mobile and others. And now, we have a thriving open source developer community consisting of engineers and innovators who may not have necessarily collaborated in the past.

These participants see benefits of collaboration not only to accelerate innovation but also to build the software run time across many different types of environments and use cases so as to increase reliability. Providers recognize that in their transformation to software networks there’s much they can do together to drive technology, while using how they define and deliver services to stand out from each other in the experiences created for customers.

What about your organization? Do you engage in the OpenDaylight community? Have you explored how ONAP can help you? Do you use OpenStack in your production network? And importantly, do you engage in the discussions and share back what you learn and develop?

Pursuit of Innovation

A third observation is the growing ability for service providers to create and innovate at levels not seen before. A prime example here is the work done by CenturyLink to develop Central Office Re-architected as a Datacenter platform to deliver DSL services running on OpenDaylight. CenturyLink used internal software development teams along with open source and Agile approaches to create and deploy CORD as part of a broad software transformation initiative.

One might have thought that you would only see this level of innovation at Google, Facebook or AWS, but at Lumina we are seeing this as an industry-wide trend. The customer base, business model, and operations of service providers vary widely from one to another based on their historical strengths and legacy investment. All have an opportunity to innovate in a way that advances their particular differences and competitive advantages.

Closing Thoughts

So we encourage you to get on the bandwagon! Don’t stand on the sidelines. A combination of leadership, collaboration and innovation are the ingredients you need to help your organization drive the software transformation needed to stay competitive. There is no other choice.

Stay tuned for my next blog where we will discuss some of the specifics of the advantages, development and innovation using open source.

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