PANTHEON.tech is the 2nd largest OpenDaylight contributor for Q3/2018

In the last week of November 2018, Bitergia, a software development analytics company, published a report on the past and current status of the OpenDaylight project, which plays a significant role in PANTHEON.tech’s offerings and solutions.

PANTHEON.tech’s CTO Robert Varga, is leading the list of per-user-contributions to the source code of OpenDaylight, with over 980 commits to the source code in Q3 of 2018. This achievement further establishes PANTHEON.tech’s position as one of the largest contributors to the OpenDaylight project.

As for the list of companies which contribute to the source code of OpenDaylight, PANTHEON.tech is the 2nd largest contributor for Q3/2018, with 1034 commits. We were just 34 commits shy of the top contributor position, which belongs to Red Hat.

Due to ODL’s open-source nature, anyone can contribute to the project and improve it in the long-run. Any change that gets added to the source code is defined as a commit. These types of changes need an approval and can not be any type of automated activity – including bot-actions or merges. This means, that each single commit is a unique change, added to the source code.

PANTHEON.tech will continue its commitment to improving OpenDaylight and we are looking forward to being a part of the future of this project.

What is OpenDaylight?

ODL is a collaborative open source project aimed to speed up the adoption of SDN and create a solid foundation for Network Functions Virtualization (NFV).

PANTHEON.tech’s nurture for ODL goes back when it was forming. In a sense, PANTHEON.tech has led the way is and how an SDN controller is and should be. This requires dedication, which was proven over the years with the extensive amount of contribution thanks to its expert developers.

Click here if you are interested in our solutions, which are based on, or integrate ODL’s framework.


You can contact us at https://pantheon.tech/

Explore our Pantheon GitHub.

Watch our YouTube Channel.

Frinx’s UniConfig is now powered by PANTHEON.tech’s lighty.io

lighty.io enables a major OpenDaylight distribution vendor to build and deploy their applications faster.

lighty.io is an SDK that provides components for the development of SDN controllers and applications based on well-established standards in the networking industry. It takes advantage of PANTHEON.tech’s extensive experience from the involvement in the OpenDaylight platform and simplifies and speeds up the development, integration, and delivery of SDN solutions. lighty.io also enables SDN programmers to use ODL services in a plain JavaSE environment.

FRINX UniConfig provides a common network API across physical and virtual devices from different vendors. It leverages an open source device library that offers connectivity to a multitude of networking devices and VNFs. FRINX UniConfig provides the ability to store intent and operational data from services and devices enables to commit intent to the network, syncs from the network so that the latest device state is reflected in the controller, compares intended state and operational state and provides device and network wide transactions. All changes are applied in a way that only those parts of the configuration that have changed are updated on the devices.

The UniConfig framework consists of distinct layers, where each layer provides a higher level of abstraction. APIs of the lowest layer provides the ability to send and receive unstructured data to and from devices. The unified layer provides translation capabilities to and from OpenConfig. The UniConfig layer provides access to the intent and the actual state of each device plus the capability to perform transactions and rollback of configurations. NETCONF devices can be configured via their native YANG models or via OpenConfig. Finally, FRINX UniConfig also provides service modules based on IETF YANG models for the configuration of L2VPNs, L3VPNs and enables the collection of LLDP topology information in heterogeneous networks.

The UniConfig Framework is based on open source projects like OpenDaylight and Honeycomb and publishes all translation units under the Apache v2 license. Customers and integration partners can freely contribute, modify and create additional device models, which work with the UniConfig Framework.

How did PANTHEON’s lighty.io  help?

PANTHEON.tech’s lighty.io helped to make UniConfig run and build faster.

Porting UniConfig to lighty.io required no changes to the application code and has brought many measurable improvements, such as UniConfig now starts faster, has a smaller memory footprint, and most importantly, significantly reduces build time.

lighty.io packs many features, some of which are:

  • Client libraries for communication with ODL back end for Java, Python, and Golang
  • Enhanced NETCONF device simulator
  • Microservice friendly structure
  • Easy to use utilities for YANG model data serialization and deserialization
  • Example applications for integration with vertx.iospring.io and others which enable your productivity
  • Inclusive of maintained examples and guides so the newcomers can start working immediately and be efficient

About FRINX  

FRINX offers solutions and services for open source network control and automation. FRINX is made up of passionate developers and industry professionals who want to change the way networking software is created, deployed and operated. FRINX offers network automation products and distributions of OpenDaylight and FD.io in conjunction with support services and is proud to count service providers and enterprise companies from the Fortune Global 500 list among its customers.

About PANTHEON.tech 

PANTHEON.tech is a software research & development company focused on network technologies and prototype software. Yet, we do not perceive networks as endless cables behind switches and routers: for us; it is all software-defined. Clean and neat. Able to dynamically expand and adapt according to the customer’s needs.

We thrive in a world of network functions virtualization and arising need for orchestration. Focusing on SDN, NFV, Automotive and Smart Cities. Experts in OpenDaylight, FD.IO VPP, PNDA, Sysrepo, Honeycomb, Ligato and much more.

 

Meet Robert Varga, PANTHEON.tech’s #ons2018 attendee

Robert Varga is PANTHEON.tech’s  Chief Technology Officer who has almost two decades of Information Technology Industry experience ranging from being a C code monkey, through various roles in telecommunications’ IT operations to architecting bleeding edge software platforms.

Robert has a deep expertise in Software Defined Networking, its applications and the OpenDaylight platform.

Within those decades, some of the technologies he had experience are: C/C++, Java, Python, various UNIX-like systems and database systems.

Robert has a very strong background in design, development, deployment, and administration of large-scale platforms with the primary focus on high availability and security.

Robert has been involved in OpenDaylight from its start, architecting, designing and implementing the MD-SAL. He is the sole top, the most prolific OpenDaylight contributor and is a member OpenDaylight Technical Steering Committee, representing the kernel projects. His code contributions revolve around key infrastructure components, such as YANG Tools, MD-SAL and Clustered Data Store. He also designed and implemented the first versions of the BGP and PCEP plugins.

 

Provided by Bitergia Analytics

Until today, Robert Varga had made 11,368 commits in 66 ODL projects over the course of ODL’s lifespan. That is 621,236 added and 524,842 removed lines of code and that translates roughly around 12 great novels written in </code>. ODL continues to be a great example of what an open-source software is and how international contributors can collaborate beautifully to create the next great thing.  There are currently only 13 TCLs in ODL who help steer the project forward and lead the ODL to be the most successful SDN controller in the world. He is proudly one of the ODL Technical Steering Committee Members and a committer to a range of projects.

The all-time top contributor of ODL  Robert Varga, Chief Technology Officer of PANTHEON.tech makes the company proud to be among the top contributor of such innovative, successful project.

Robert shares the PANTHEON.tech’s ambition to create the biggest and most successful open-source Software Defined Networking (SDN) controller in the world.

Robert will be available to share his deep expertise in the field and representing PANTHEON.tech the silver sponsor of Open Networking Summit Europe which will take place on Sep 25-27 in Amsterdam.

Join Robert at PANTHEON.tech’s booth #14 in the event to get a glimpse of the Software Defined Networking future.

 

PANTHEON.tech has released lighty.io 9.0 and it is fully compatible with OpenDaylight Fluorine

PANTHEON.tech is proud to announce the release of lighty.io 9.0 following the official  OpenDaylight Fluorine release.

lighty.io has been adapted to reflect the latest upstream changes and made fully compatible with.

Check out our latest lighty.io release on our GitHub account.

Here are some noteworthy improvements what OpenDaylight Fluorine established:

  •  Yangtools cleanup and refactoring.
  •  Streamlined generated Yang module APIs.
  •  Improved Java bindings.
  •  NETCONF and RESTCONF improvements.

The biggest ODL improvement is the new set of core services provided by the MD-SAL project. Older services provided previously by the controller project have been marked as @Deprecated and will be removed in future ODL/lighty.io releases.

lighty.io provides new MD-SAL services as well as @Deprecated controller implementations.

Please see lighty.io Services for reference.

If your application uses any of the @Deprecated marked services, you should consider refactoring. Contact us for any troubleshooting requirements.

In addition to the latest ODL improvements, lighty.io has more to offer:

  • Up-to-date web server Jetty 9.4.11.v20180605 with better HTTP2 support.
  • RESTCONF implementations are now in compliance with HTTP2.
  • YANG actions implementation as it was defined in RFC 7650.
  • gNMI / OpenConfig south-bound plugin.
  • Minor changes leading the controller to startup faster
  • Improved Javadoc for main APIs.
  • The easier pathway towards JDK 11 adoption.
  • Spring.io dependency injection integration.
  • And many more, please check them out on the lighty.io web.

The list of the @Deprecated and added new services is below. 

List of the new MD-SAL services:  List of the @Deprecated services:
org.opendaylight.mdsal.binding.api.DataBroker

org.opendaylight.mdsal.binding.api.MountPointService

org.opendaylight.mdsal.binding.api.NotificationPublishService

org.opendaylight.mdsal.binding.api.NotificationService

org.opendaylight.mdsal.binding.api.RpcProviderService

org.opendaylight.mdsal.binding.dom.codec.api.BindingCodecTreeFactory

org.opendaylight.mdsal.binding.dom.codec.api.BindingNormalizedNodeSerializer

org.opendaylight.mdsal.dom.api.DOMDataBroker

org.opendaylight.mdsal.dom.api.DOMDataTreeService

org.opendaylight.mdsal.dom.api.DOMDataTreeShardingService

org.opendaylight.mdsal.dom.api.DOMMountPointService

org.opendaylight.mdsal.dom.api.DOMNotificationPublishService

org.opendaylight.mdsal.dom.api.DOMNotificationService

org.opendaylight.mdsal.dom.api.DOMRpcProviderService

org.opendaylight.mdsal.dom.api.DOMRpcService

org.opendaylight.mdsal.dom.api.DOMSchemaService

org.opendaylight.mdsal.dom.api.DOMYangTextSourceProvider

org.opendaylight.mdsal.dom.spi.DOMNotificationSubscriptionListenerRegistry

org.opendaylight.controller.sal.binding.api.NotificationProviderService

org.opendaylight.controller.sal.binding.api.RpcProviderRegistry

org.opendaylight.controller.md.sal.dom.spi.DOMNotificationSubscriptionListenerRegistry

org.opendaylight.controller.md.sal.dom.api.DOMMountPointService

org.opendaylight.controller.md.sal.dom.api.DOMNotificationPublishService

org.opendaylight.controller.md.sal.dom.api.DOMNotificationService

org.opendaylight.controller.md.sal.dom.api.DOMDataBroker

org.opendaylight.controller.md.sal.dom.api.DOMRpcService

org.opendaylight.controller.md.sal.dom.api.DOMRpcProviderService

org.opendaylight.controller.md.sal.binding.api.MountPointService

org.opendaylight.controller.md.sal.binding.api.NotificationService

org.opendaylight.controller.md.sal.binding.api.DataBroker

org.opendaylight.controller.md.sal.binding.api.NotificationPublishService

 lighty.io by PANTHEON.tech

PANTHEONtech at Open Networking Summit (ONS) 2018

PANTHEONtech had a unique opportunity to participate on Open Networking Summit (ONS) 2018 this year. Central topic of the ONS 2018 was data center solutions: ONAP and Kubernetes based systems. Also few new projects under the wings of Linux Foundation were introduced. For example “Acumos AI“, “Arkaino Edge stack” and DANOS (Disaggregated Network Operating System project) which is the operating system for white-box switches.

 

PANTHEONtech has traditionally participated on the OpenDaylight (ODL) as well as the fd.io development and we launched our lighty.io product in the ONS. lighty.io changes conventional OpenDaylight attitude on how to build SDN controller applications, making them smaller, nimble and micro-service ready.

lighty.io caught attention of the ODL community members as well as customers struggling with real-life ODL deployments. This solution helps to consume and deploy ODL services faster with lower cost of ownership. Faster builds, quick test runs and smaller distribution sizes are right way to proceed. lighty.io brings also added value into the ONAP eco-system providing runtime for ONAP’s SDN-C link to sdn-c blog/article. We are continuously updating the community with lighty.io use-case examples and also lighty.io video use-cases

 

One of the projects, in which we participate in the community, is The Fast Data Project (FD.io). For the FD.io community, we presented Ligato; Honeycomb’s younger brother. It is an ’easy to learn and easy to use’ integration platform. We love to see, that the FD.io community is growing larger, not only in the number of contributors, but in the number of projects and use-cases as well. We were also pleased to accept an invitation to an introduction of a new FD.io project “Dual Modes, Multi-Protocols, Multi-Instances” (DMM), where we discussed use-cases and integration paths from the current networking stack. FD.io community has a potential of further growth, especially as we see the shift of the networking industry from a closed-sourced hardware-based network functions to an open-source software-based solutions.

ONS 2018 was an exciting opportunity for us. It was a forum where we could easily share our knowledge and provide a much needed innovation. Let’s see how artificial intelligence and machine learning will change the landscape of networking in upcoming years. See you on next ONS event!

 

Yangtools-2.0.1 is out and integrated in OpenDaylight Oxygen

OpenDaylight’s YANG Tools project, nick-named yangtools, forms the bottom-most layer of OpenDaylight as an application platform. It defines and implements interfaces for modeling, storing and transforming data modeled in RFC7950, a.k.a. YANG 1.1 — such as a YANG parser and compiler.

Pantheon engineers started yangtools some 5 years ago, originally supporting RFC6020, going through a number of verions, before finally releasing yangtools-1.0.0 and with it semantic versioning as an API contract. Since then we have retrofitted original RFC6020 metamodel to support RFC7950 and implemented the corresponding parser bits, which were finalized in yangtools-1.2.0, hich shipped with Nitrogen Simultaneous Release.

This release entered its development phase on August 14, 2017 and yangtools-2.0.0 was released on November 27, 2017, which is when the search of an integration window started. Eventhough we had the most critical downstream integration patches prepared, most of downstreams did not have their patches even started. Integration work and coordination was quickly escalated to the TSC and the integration finally kicked off on January 11, 2018.

The integration was mostly complicated by the fact that odlparent-3.0.x was riding with us, along with the usual Karaf/Jetty/Jersey/Jackson integration mess, but it is now sorted out, with  angtools-2.0.1 being the release to be shipped in Oxygen Simultanenous Release.

So what is new in yangtools-2.0.1?

Quite a lot based on code movement statistics:
– 309 commits
– 2009 files changed
– 54126 insertions(+), 45014 deletions(-)

Which is not that surprising, given that 2.0.0 gave us the opportunity to break APIs in 18 months. That does not really tell the story, though, so here is a run-down of what lies behind those numbers.

The most user-visible change is that in-memory data tree now enforces mandatory leaf node presence for operational store by default. This can be tweaked via the DataTreeConfiguration interface on a per-instance basis, if need be, but we recommend against switching it off.

For downstream users using karaf packaging, we have split our features into stable and experimental ones. Stable features are available from features-yangtools and contain the usual set of functionality, which will only expand in its capabilities. Experimental features are available from features-yangtools-experimental and carry functionality which is not stabilized yet and may get removed — this currently includes ObjectCache, which is slated for removal, as Guava’s Interners are better suited for the job.

Users of yang-maven-plugin will find that YANG files packaged in jars now have their names normalized to RFC7950 guidelines. This includes using the actual module or submodule name as well as capturing the revision in the filename.

From API change perspective, there are two changes which stand out. We have pruned all deprecated methods and all YANG 1.1 API hacks marked with ‘FIXME: 2.0.0’ have been cleared up. This results in better ergonomics for both API users and implementors.

yang-model-api has seen some incompatible changes, ranging from renaming of AugmentationNode, TypedSchemaNode and ChoiceCaseNode to some targetted use of Optional instead of nullable returns. Most significant change here is the introduction of EffectiveStatement specializations — I will cover these in detail in a follow-up post, but these have enabled us to do the next significant item.

YANG parser has been refactored into multiple components and its internal structure changed to hide most of the implementation classes and methods. It is now split into yang-parser-reactor  language-independent inference pipeline), yang-parser-rfc7950 (hosting baseline RFC6020/RFC7950 parser), yang-parser-impl (being the default-configured parser instance) and a slew of parser extensions (RFC6536, RFC7952, RFC8040). There is a yang-parser-spi artifact, too, which hosts common namespaces and utility classes, but its layout is far from stabilized. Overall the parser has become a lot more efficient, better at detecting and reporting model issues and implementing new semantic extensions has become really a breeze.

YANG codecs have seen a major shift, with the old XML parser in yang-data-impl removed in favor of yang-data-codec-xml and yang-data-codec-gson gaining the ability to parse and emit RFC7951 documents — allowing RFC8040 NETCONF module to come closer to full compliance. Since the SchemaContext is much more usable now, with Modules being indexed by their  NameModule, the codec operations have become significantly faster.

Overall we are in a much better and cleaner shape. We are currently not looking at a 3.0.0 release anytime soon and can actually deliver incremental improvements to YANG Tools in a much more rapid cadence than previously possible with the entire OpenDaylight simultaneous release cycle being in the way.

We already have another round of changes nearly ready for yangtools-2.0.2, watch this space for an update around that next week.

 

Robert Varga

Moscow business district under construction

Building Infrastructure Systems 2017 Conference, Moscow

At the end of October 2017, I had a chance to visit one of the world’s largest cities – beautiful Moscow, capital of Russia, where the BIS 2017 event took place. BIS – Building Infrastructure Systems – focused at data centers, networks and technologies connected to these topics. The venue was the impressive Azimut Olympic hotel, which pleasantly surprised everyone by being a fully smoking-free zone with lots of photos on the walls picturing healthy ways of life.

Moscow business district under construction

The event was very well organized and the timing precise; everything was on time and easy to find. The event was attended by nearly 1000 delegates, among them many representatives of businesses and government bodies, highly skilled technical specialists and CxOs managing large companies. Since the very beginning I literally had no time to sit down for a while, such was the number of visitors to our booth. Most of them showed great interest in our company’s scope of work, the level of expertise we provide, projects we participated at; and there were hundreds of other questions they wanted to ask 🙂

BIS 2017 Moscow servers

At 11:20 of the event day, we had a presentation slot allocated to Pantheon Technologies. The room was full of people, showing great interest in the SDN, NFV and IoT technologies. I have had 15 minutes to discuss the latest trends in SDN and NFV and to introduce our company to the audience. Unfortunately, there was almost no time left for the Q&A part, so I invited everyone to our booth. And people came. Right after the presentation, and until the very end of the day, people kept coming and asking questions, asking for references, contacts. That was truly amazing!

BIS 2017, Moscow, Pantheon Technologies brochures

I’ve spoken to people from the Government of Moscow, from financial bodies, telecom and development companies. There were several representatives from largest Russian system integration companies who were interested in cooperation.

At the same time, it was inspiring to listen to their practical “field” experience and their understanding of the market. The overall impression I had is that the SDN/NFV technologies are being actively researched and tested in Russia recently, although significant ROI is still a rare case here. We need more work and time until that point is reached.

BIS 2017, Moscow, robot

My final impression was that we came to show Pantheon Technologies to Russia just in the right time. There are many interesting projects out there where our long-term expertise in the field of networking software development may prove useful.

 

Denis Rasulev

Carbon Cluster / cloud picture

Quick Carbon Cluster Setup in Amazon Cloud

Have you ever needed to setup an SDN controller cluster? Did you do it manually? Did it not take too long?

No worries – since we’ve got you covered from now on, you can automate your setup using our CloudFormation 3-node cluster template with Pantheon Technologies’ Carbon SDN controller.

The recipe is quite straightforward. Use your Amazon account to subscribe to the Carbon product here (or look here to check out the instructions how to do it). Open the CloudFormation console. Start creating a new „stack.“ Continue with feeding the creation wizard with our template, which is available here. Fill the customization parameters – that goes something like this:

Carbon Cluster configuration

Some parameters will be pre-filled with default values. Other parameters must be filled manually. For instance, you have to be creative and name your stack. You’ll also need to select a virtual private cloud (VPC), which will be something like your own private playground in the Amazon cloud.

Don’t worry – every Amazon account which is not too old should have one by default. Just use the combobox and click “select.”

 

Carbon Cluster / cloud picture

The last thing is the SSH access key pair that is also used for the automatic cluster configuration. Due to the private key upload, I would recommend you to create a new key pair just for this purpose (look here).

Additionally, you can define basic machine parameters of your nodes by choosing the correct instance type. You can also enhance the security by reducing the reachability of certain ports.

After filling the parameters, you can leave the other wizard pages untouched and finish with the creation wizard. After some 11 minutes, the cluster will be up and running.

Now you can play with it as much as you wish. You can access its nodes using SSH (see the „outputs“ tab of your stack) or you can access the data model of the Toaster example using the RESTCONF and simulate cluster failovers. Last but not least, our marketing department wants us to mention that the Carbon SDN controller costs you nothing. It’s free, so that you can try it out and decide whether you like it or not.

 

Filip Gschwandtner

Senior Software Engineer

 

Singapore skyline

Pantheon Technologies visited TechXLR8 in Singapore

Looking for customers and partners in new markets is an essential part of portfolio diversification strategy. New markets bring new opportunities, new insights, needs and challenges. Hence, at the beginning of this October, with my colleagues Denis and Robert we travelled to Singapore in search of all of the above-mentioned. We’ve anticipated finding it all at the huge TechXLR8 event, sponsored by Pantheon Technologies, which comprised of smaller happenings: 5G Asia, IoT World Asia, NV & SDN, the AI Summit and Project Kairos Asia. Being the Silver Sponsor at such a vast event was a brand new experience for us.

Singapore skyline

We’ve spent two days discussing SDN and networking, introducing Pantheon Technologies and our products to the representatives of Asian market. We also had an opportunity to take part in a panel discussion on NFV MANO interoperability and how it fits into the open source world along with related standardization being done by ETSI.

This discussion, more than anything else, showed our presence to other attendees. So, we talked, smiled and explained. People were interested in Visibility Package which we have demonstrated. They asked a lot about the company and our contribution to OpenDaylight, as well as other open source projects we are part of, or have experience with.

 

SDN, OpenDaylight and the others

Pantheon Technologies was not the only company promoting OpenDaylight-related solutions. Official OpenDaylight members were present, as well as other companies and groups offering their ODL based solutions. We have received several offers for cooperation from several company representatives advertising their ODL and SDN-related skills. This clearly indicates the importance of the OpenDaylight project.

IoT is the word

Despite TechXLR8 being crowded with companies presenting different IoT solutions and despite having our booth placed at NFV/SDN area, we have received a great number of IoT-related questions. We talked about IotDM as of oneM2m compliant data broker for ODL. For some people, oneM2M was just another buzzword. They were frequently asking about specific use cases related to the IoT field. Our question, “what do you need?” still hangs there waiting to be answered. Asia seems to be searching for its answer on what IoT stands for. There are open opportunities for us to help finding an answer for this question.

 

Man in the middle

Along all the companies presenting their products, skills or ecosystems, there was one special group of people present. They usually introduced themselves as “the company that represents telco in Asia.” Who were these people?

Asian markets are quite different from what we have experienced so far, in a way how companies search for partners and how partnerships are being built. There are many companies acting as matchmakers. It seems that a significant number of telco companies doesn’t actively search for partners, but rely on matchmakers. Matchmakers actively seek solutions or vendors who might match their telco customers. What do matchmakers have to say about their customer’s expectations?

Singapore conference - people mingling

All of them had pretty much the same answer. We need to approach companies with our solutions and make them think it is what they need. As if only thing market is looking for was advantage over competitors. Whatever solution will make that happen. Even that we can’t honestly say there is a market driving vision missing, it for sure feels that way. Presence of buzzwords without focus on specific case indicates that Asian telco and IT market has evolved differently as markets we use to operate.

 

Hic abundant leones

The best way to describe our first encounter with the Asian market is mapping terra incognita, the unknown land, place where lions are. We’ve made the first step towards the unknown and have found some potential partners on the way. Now we have to figure out how to turn the first contact into a working partnership and collaboration. We need to find a specific use case, or set of use cases, to show to potential customers in Asia, but we aren’t quite sure what to show and whom to show it. Finding that out is our next goal. Find use case to make a showcase of and find audience for it. For that, we need to flood the matchmakers we already know and also keep looking for new ones.

Singapore event - building Pantheon stall

Lesson learned

Are our solutions tailored to fulfill specific needs? Indeed they are. Do our solutions bring variety and scalability? Definitely. Can we deliver? Yes we can. Next time, we have to show that more explicitly. We need to prepare showcases that would amaze people. We need to find equilibrium between our skill and the market’s desire for buzzwords. It does not need to be product quality, does not even need to be a product by itself. It just needs to show – hey, we are the right ones.

Was our journey a success? Our journey to Singapore was a success. Journey to Asian markets has just begun. It is our job to make the most out of it.

Martin Bobák

Technical leader

moscow business district

Ready to Discuss Automation, Data & Networks in Moscow?

Already on October 25, 2017, a very special event will be taking place in Moscow: CIS Event Group’s BIS 2017 / Around Networks, Around Automation, Industry 4.0.

If we had to pick one single event focused on modern engineering infrastructure where we could meet our friends, peers and clients from Russia and the neighboring countries, this would be the one.

moscow business district

Let us introduce ourselves to the Russia’s market: Pantheon Technologies is among the leaders in Network Function Virtualization with deep expertise in the Internet of Things, Software Defined Networking, OpenDaylight and several other fields, such as Sysrepo, Honeycomb and Ligato. As these technologies are gaining traction in Russia and starting to spread throughout the neighborhood, now the time has come for us to get more involved and offer our expertise where it is required most.

We are working towards developing the future of the internet. Are you ready to join?

 

Denis Rasulev

books database cassandra datastore

Give us a requirement, we’ll provide a solution: Cassandra Datastore

As a company with highly skilled people and experience in networking and ODL, Pantheon Technologies provides solutions to any problem or requirement our clients bring up. In this case, we are going to illustrate what we can do on showcasing the workflow of a project.

 

Identifying a need

The first step was to identify a need; one of the main issues of working with datastore is that we lose data when the Controller goes down.

book repository Cassandra datastore data, picture shows a library

Proposing a solution

Once we’ve identified the need, we start looking for possible solutions, analyzing each one’s pros and cons, looking for the best answer available. In this case, the best available solution was to replace the in-memory ODL datastore with a persistent database: the Cassandra Database.

 

What is Cassandra?Cassandra logo small

If you need scalability and high availability without compromising the performance, the Apache Cassandra database is the right choice for you. It is the perfect platform for mission-critical data thanks to linear scalability and proven fault tolerance on cloud infrastructure or commodity hardware. Cassandra is able of replicating across multiple datacenters and it’s best in the class. With her, your users are provided with lower latency – and you with a peace of mind, if you realize how simple surviving a regional outages is.

 

Defining the solution requirements

We need to define the requirements for the proposed solution: what will it do, and how, requirements from the user, etcetera… For this project, we’ve decided that the user would need to register the service at a specific prefix, pointing at a specific path on shard which the user is interested in storing. The service will be listening to any changes under this subshard, and whenever the information is updated, it will take care of transforming the information into the JSON format, and store it in Cassandra.

Cassandra datastore benefits

Implementing the solution + testing

We’ve defined the requirements and have selected the solution. We’ve identified the steps required/wanted to achieve the results expected. Based upon them, we’ve created the tasks required and have implemented them. Finally, we shall test the result. We can see some of the anticipated results in the table below.

Cassandra values

  • Rate:         Writes per second rate.
  • Duration:  Request duration in milliseconds.
  • Count:       An amount of changes applied simulated

* Benchmark, Karaf and Cassandra were running under same Virtual Machine, with 8G RAM and 4 Processors dedicated.

 

Use cases

We’ve identified one use case for this project, which was to have a persistent datastore. But the list of possible benefits does not end there. Given the case that we were storing the OpenFlow statistics, we could beneficiate from having that information using Spark for applying Real time data analytics & visualization on it, allowing us to react and improve our network by, for example, banning or redirecting heavy traffic. Once we have the information, everything we need is to pick up the fruit.

For more information, please feel free to contact us via sales@nullpantheon.tech

Claudio David Gasparini

SDN NFV Hague Conference / Binnenhof with tulips

Sponsoring the SDN NFV World Congress Confirmed

In mid-October, the SDN NFV World Congress will dominate Europe’s IT landscape. Taking place in Netherlands’ Hague, the event is Europe’s largest dedicated forum addressing the growing markets of software-defined networking (SDN) and network functions virtualization (NFV).

SDN NFV Conference - the Hague

Naturally, this is the type of event we at Pantheon Technologies gravitate towards sponsoring. Long story short, we’re one of the partners. There were already a couple of interesting names on board (Open Networking Foundation, Intel, Telefonica, BT, Konia, Orange…) so how could we be the one to miss out?

If you’d like to hear about technologies such as OpenDaylight, FD.io, OPNFV and many more – and learn about the magic we can work with them, we’ll be looking forward to talking to you live! Also, if you just want to know us, or only have a chat, feel free to drop by!

Martin Firak

blog - Singapore Tech XLR8 Asia 600x373 px

Pantheon partners up with TechXLR8 Asia

We’ve already started establishing a tradition of Pantheon Technologies partnering with the best tech events around the globe. To keep up with it, we’ll be sponsoring the Network Virtualization & SDN Asia conference, which will be taking place this fall in Singapore as a part of TechXLR8 Asia. On board with partners such as Juniper Networks, Fujitsu and VMware, we’ll be joining as a silver sponsor.

 

Singapore Marina Bay Sands hotel

What does this mean in practice? Our colleagues will be able to showcase the Pantheon skills and know-how both as speakers and in the exhibition area.

As we were recently proven at TechXLR8 London, our portfolio is quite unique. The topics revolving around ODL, SysRepo, FD.io, Honeycomb and Vector Packet Processing have struck the cord. Not only that we’ve met lots of interesting people from telco, SDN and content delivery companies, but our business card supply wasn’t able to cover the demand!

Is there anything specific you’d like to hear us talk about?

See you in Singapore on October 3-4!

Martin Firak

ODL Santa Clara

OpenDaylight Developer Design Forum 2017: Nitrogen

On a regular basis, OpenDaylight (ODL) developers meet in order to discuss their ideas as well as plans for upcoming releases. Pantheon Technologies’ Robert Varga and Vratko Polak have joined this year’s gathering. Vratko’s account of the event follows.

OpenDaylight Developer Design Forum 2017: Nitrogen

Brief introduction to ODL

OpenDaylight is an open source project aimed at supporting Software Defined Networking, mainly through a Java application (also called ODL). It’s capable of communicating with network elements via various protocols (southbound) while accepting requests from humans and other programs (northbound), again, via various protocols (although RESCONF is currently the main one).

ODL as a project is hosted by the Linux Foundation (LF), but has its own governance. ODL itself consists of (sub)projects, each has its own Git repository, committers and Project Lead. The Technical Steering Committee (TSC) allows creation of new projects, archival of old projects, and provides guidance for inter-project matters. Most projects focus on providing code for the Java application, so most of their code is in Java, together with Maven definitions used to build artifacts. Those projects depend on each other, ODLParent is the most “upstream” of such projects. Leaf projects are those which do not have other ODL Java project depending on them, not counting Integration/Distribution, which is a project aggregating all artifacts of a particular release into a file archive containing ODL installation.

Integration/Test then runs system tests (CSIT stands for Continuous System Integration Testing) against this archive. Both building and testing is done in Jenkins, Releng/Builder is the project responsible for configuring those Jenkis jobs (and other minutae of infrastructure). In between releases, ODL projects build Snapshot artifacts that are stored in a Nexus server, so artifact version does not define a unique code, and there are possible race conditions when one job uploads new artifacts while other job downloads them. To avoid these downsides, Releng/Autorelease is a project which downloads all the code, bumps it to a non-snapshot version, builds that, and uploads to a staging repository, thus creating a release candidate. Integration/ and Releng/ projects are examples of Support projects.

ODL releases are named after periodic table elements. This Forum has taken place just after the Carbon release, and its goal was to bring developers together in order to speed up discussion and planning of the Nitrogen release. One of the few things every project has to agree with, is the choice of the Java container. From Beryllium up to Carbon, the container of choice was Karaf, versions from the 3.0.x series. Karaf is a Java container based on OSGi. The main concept in Karaf is a Feature, which can contain OSGi bundles, config files and other Karaf features. ODL seems to be using Karaf features in a slightly different way from what Karaf developers have intended, therefore the Carbon initiative to upgrade to Karaf 4 has failed. Previous ODL releases tended to come in roughly 8-month cycles. But ODL is now part of larger ecosystem of networking-focused projects, so TSC decided to change to a 6-month cycle. And to fit into a correct slot, Nitrogen is scheduled to be released only 4 months after Carbon, with upgrading to Karaf 4 as its main goal.

The Developer Design Forum (DDF) for Nitrogen has taken place in Hotel Marriott, Santa Clara, California. The official program was two days long, opening on May 31 and concluding on June 1, 2017. DDF gatherings usually consist of scheduled “conference” sessions, accompanied by parallel “unconference” sessions, created on the spot. Compared to previous DDFs, there were less participants than usual (roughly 50 compared to 150 in the past), leading to only one meeting room being used for conferences and leaving the other available for unconferences.

A list of sessions that I attended follows, together with short descriptions. Please note that the descriptions (and session names) are very loose paraphrases of what was actually discussed, based rather on my personal impressions than the official program.

 

Karaf 4 planning conference session

After reiterating facts about Nitrogen being a “short” release focused on Karaf 4 transition, a rough timeline was presented. It was stressed that active participation of all projects is required. Projects too slow to respond will be dropped from the release mercilessly.

ODL DDF Nitrogen karaf logo

Not many technical details were discussed at this point, aside from notifying projects that there will be a time period where usual build and test jobs will not be running (at least not for every project) as incompatible changes will require time for rebuilds, to be performed in order throughout the project dependency graph.

 

Emergency leaf project removal plan unconference session

Around half of current projects are in dormant state, not being developed anymore, usually with only one person performing critical maintenance in their spare time. It is expected that multiple projects in this state will be unable to perform their Karaf 4 migration duties in time. Therefore, many Carbon projects are not going to make it into Nitrogen official release. Yet, there is a backup plan in place, at least for leaf projects: they could release their artifacts in a standalone release. That means their artifacts will not be built within the usual Autorelease job. Releng/Builder can create a job template for that kind of release, so that project won’t need much work to perform such release. Integration/Test would need more changes to allow CSIT for such projects, but we do not envision many projects asking for that.

 

ODLParent standalone release unconference session

It is a long-standing plan to “decentralize” the ODL release process, so that it depends less on Releng/Autorelease forcing everyone to release at the same time. ODLParent will be the first project to do separate releases (and still end up in Integration/Distribution builds). This needs a new job template, basically the same one as for the removed leafs. Version bumping in downstream will be somewhat painful at first, but the Autorelease project already has all the scripts and rights needed, and an automated job can be created later.

 

Karaf 4 specific changes unconference session

In Carbon it was discovered that two main ways to install features (the featuresBoot configuration line and feature:install runtime command) use different code paths in Karaf 4, and therefore supporting both of them might not be possible. If Linux Foundation pays a Karaf developer, it might become possible, but we cannot count on that within the Nitrogen cycle. The first Karaf 4 ready ODLParent release will drop support for Karaf 3, Integration/Distribution will stop building Karaf 3 distribution, and all CSIT testing will be switched to Karaf 4. That means we do not need to support a transition period of both versions being built and tested at the same time. If we decide to only support feature:install, changes to Releng/Builder scripts (for CSIT) will be needed.

 

Releng/Builder needed changes unconference session

This was a technical session, hashing out details of how items from the two previous sessions will be implemented. Few general enhancements were also discussed briefly, however, with no plans of implementing them in the Nitrogen cycle.

 

Jira instead of Bugzilla conference session

There is a long-standing plan of migrating from Bugzilla to Jira. We’ve discussed several technical reasons why we really need that, as well as a few risks involved. The general consensus is that we want Jira, but it takes some work and we need a person to take the responsibility and make it happen. Not likely within Nitrogen.

 

ODLParent planning conference session

Technical explanation of what went wrong with Karaf 4 in Carbon. We have a general plan to finally fix that, consisting of 4 approaches we intend to try. Explicit steps of how ODLParent standalone releases and Karaf 4 support will be done, with milestones and deadlines for ODLParent, Java projects, Integration/Distribution and Integration/Test. There will be at least one period where the usual Jenkins jobs will not work, perhaps more if multiple ODLParent releases are needed. Karaf 3 support will be propped as soon as possible, so that projects are motivated to help their upstream with migration.

ODL DDF Nitrogen writing

Integration/Test planning unconference session

Few ideas were mentioned, but they were postponed in general, as Karaf 4 migration will consume most of the time. The old plan of migrating ODL installation logic from Releng/Builder bash scripts to Robot Framework suites is still good, but demanding. General Robot code maintenance will remain a slow gradual process. Having a small set of reliable “sanity” tests is still desired. We have a stub already running; all we need is to add more suites which are stable and quick enough. Test result availability and comprehensibility is still a major issue. The current plan is to export the test results to a database, and have a dashboard to render results in a user-friendly way. We have new interns to work on both steps.

 

MD-SAL usage conference session

A highly technical session where our colleague from Pantheon Technologies, Robert Varga, was talking about the ways MD-SAL (Model Driven Service Abstraction Layer) can be interacted with. Each has its pros and cons. Single listener subscribed to a set of subtrees seems to be the approach avoiding the most of pitfalls, but the cluster implementation is not ready yet.

 

Infrastructure and CSIT, retrospective and improvements conference session

The changes to Integration/Test and Releng/Builder done in Carbon. Current gaps and how we plan to bridge them, rehashing some ideas from the unconference earlier.

 

Upgrade-ability conference session

initially, we will be satisfied with reliable offline upgrades. We know that there are significant API changes between releases, and MD-SAL lacks a service which would tell the user that ODL has finished booting up. ODL has a built-in persistence, but some of it is cleared on startup and, perhaps, also corrupted on shutdown. Nevertheless, companies that create ODL-based solutions usually have a way to transfer data from earlier to later version of ODL, so it should be possible to create a basic mechanism in ODL itself. The Daexim project provides a basic set of tools, but it is not equipped to handle data structure changes caused by API changes in each project. The ODL core can help by sticking to the current schema.

 

Service recovery mechanisms conference session

As the ‘uninstall’ feature does not really work correctly in ODL, current recovery options are limited to restarting the Java Virtual Machine. However, some services present in ODL support a softer restart on demand. A simple model was presented to abstract services and some actions on them, which would allow a client application to query service state and cause a restart without knowing details of a particular service implementation.

 

Unit testing async code conference session

One of the criteria for ODL code quality is test coverage. Instead of testing each class as a unit, a higher-level “component” tests are the more common option. They still rely upon JUnit executed during a Maven build, but they test a construct consisting of several classes wired together. This is quite positive, as a “real” unit test would frequently have more complicated assertions, and it would still not be clear whether a composite would behave correctly (while such unit tests would take significantly longer to develop). During Carbon development, a significant progress has been achieved in the wiring part of component tests, yet there still is one area that needs improvement: most of ODL code is asynchronous, which means the component consists of several Java threads running concurrently.

One issue is that JUnit requires the assertion to be executed in the main thread to take effect. Another issue is that many asynchronous components lack visible intermediate state changes, which the main thread could check. Most current tests just use sleep for a fixed time before launching the final assert. However, everybody knows, that a test which relies on sleep is a bad test. The ideal solution would be for each class within a component to support dependency injection of asynchronous building blocks, such as executors and listeners. That way the component test can inject specialized building blocks with all hooks the test needs. Failing that, the cheapest solution is to use Awaitility, which, basically, spins an assert (not changing the state) until it passes, or a predefined time runs out. That is better that sleep in that it can pass more quickly.

 

Closing remarks conference session

The closing session mostly consisted of discussing, why we were joined by way less attendees than is usual. What can be done? One possibility is to merge the Developer Design Forum with some other LF event, however, people argued that this would take away focus from ODL planning. Another option is to ask member organizations to provide the venue, so that a smaller event like this could be hosted without hotel-high venue cost.

Vratko Polák

TechXLR8, London

In mid-June, the TechXLR8 multi-genre tech festival took place in London. Although being part of the London Tech Week 2017, it comprised of further eight ‘smaller’ events: 5G World, IoT World Europe, Cloud & DevOps World, Apps World Evolution, VR & AR World, AI & Machine Learning World, Connected Cars & Autonomous Vehicles Europe and Project Kairos.

Well, ‘smaller’ events… We are talking about a happening with more than 15 000 participants from 8 000 companies catered to by more than eight hundred tech guru speakers. Thus, these were not really what you would call small family gatherings…

Since it was, from a global perspective, one of the key industry meetings, Pantheon Technologies could not have missed it. We’ve participated in TechXLR8’s Cloud & DevOps World section where we showcased our SDN, ODL and networking skills and know-how: we’ve seen a lot of great things, we’ve managed to acquire interesting contacts with international companies active in telco, content delivery and SDN segments. Products from our portfolio such as SysRepo, ODL, HoneyComb, VPP, FD.io turned out to be really great topics for discussion.

Which keywords did the participants respond to best? Linux Foundation, OpenStack, Docker, Kubernetes, BigData. The demand for Pantheon’s business cards was so high that it caught us by surprise. We even had to ration them on the last day, such was the appetite for Pantheon!

Juraj Veverka

OpenDaylight RPCs or What Could Possibly Go Wrong With Adding This One Cool Feature

OpenDaylight uses YANG as its Interface Definition Language. This is an architecture decision we have made way back in 2013 and it works reasonably well for the most part.

One of YANG concepts used rather heavily is the concept of an RPC. For YANG and its intended use in NETCONF’s client/server model it works perfectly fine, but trouble starts brewing when you borrow concepts and try to make them fit your use case.

OpenDaylight uses YANG RPCs to not only define its northbound model, but also model interactions between its individual plugins. It does this in an environment, which is a single process, but rather a cluster of nodes, each having a mesh of plugins, some activated some not.

From architecture’s view, which looks at things from an elevation of 10,000 feet, the problem of making RPCs work in this sort of environment is quite simple: all you need are registries and request routers. From implementation perspective, though, things can easily go wrong… implementations have bugs, quirks and limitations which are not immediately apparent. They just surface when you try and push the system closer to its architectural limits.

The Trouble with Names

RFC 6020 defines only the basic RPC concept and assumes there is a single implementation servicing any request for that RPC. This is okay as long as you are targeting singleton actions — like ‘ping IP’, ‘clear system log’ and similar. In a complex system, though, requests are typically associated with a particular resource — like ‘create a flow on this switch’. Since YANG did not give us this tool, we have decided to create an OpenDaylight extension to allow an RPC to be bound to a context. This gave rise to two unfortunate names: ‘Global RPCs‘ and ‘Routed RPCs‘, the first being normal RPCs and the second being bound to a context. Plus, a third name, ‘RPCs‘, to refer to either one of those concepts. Are you confused yet?

The initial implementation of these concepts was done back in 2013, when there was no clustering in sight, by a team who have spent days upon days discussing the difference. When clustering came into the implementation picture, in 2014, the implementation team attached their own meaning to the word ‘Routed’ and we ended up with an implementation, where Routed RPCs are routed between cluster nodes, but the default ones are not. That is the subject matter behind BUG-3128. It did not matter much as long as all cluster-enabled applications used Routed RPCs, but that changed with emergence of Cluster Singleton Service and its wide-spread adoption among plugins.

These days we have YANG 1.1, defined in RFC 7950, which has the same underlying concept with much less confusing names. ‘Global RPCs’ are ‘RPCs‘. ‘Routed RPCs’ are ‘actions‘. Since those terms make the conversation about semantics a reasonable affair, this is the last you hear about Global and Routed RPCs from me.

Fun with Concepts, Contexts and Contracts

In order to support both RPCs and actions, OpenDaylight’s MD-SAL infrastructure has to define a concept to identify them both. Since the two are utterly similar in what they do, DOMRpcIdentifier was born. It is used to identify either an action or an RPC. To do that is is an abstract class with two concrete, private final implementations: DOMRpcIdentifier$Global and DOMRpcIdentifier$Local. Why those names? I do not remember the details, but I could wager a guess about what I was thinking back then. At any rate, the two implementations differ only in their implementation of DOMRpcIdentifier.getContextReference(). DOMRpcIdentifier$Global’s is always empty and DOMRpcIdentifier$Local’s is always non-empty.

This is consistent with how RPCs (without a context reference) and actions (with a context reference) are invoked and it makes the API involved in the context of RPC/action invocation clean and simple. API contract. In the context of registering an RPC or action implementation, things are slightly less straightforward. It is a separate interface, with a rather terse Javadoc. In both cases there is a hint of ‘a conceptual dynamic router’, but not much in terms of details.

Unless you were very curious as to the details of the API contracts involved, after reading the documentation available, with some OpenDaylight tutorials under your belt, you would feel this is a dead-simple matter and just use the interfaces provided. Run a few test cases and everything works just fine. No trouble in sight.

About That Router Thing…

The Simultaneous Release name of OpenDaylight for the release currently in development is Carbon, meaning we have shipped 5 major releases, so this ‘dynamic router’ thing vaguely referenced actually exists somewhere and it does something to fulfill the API contracts imposed on it, otherwise the applications would not be able to work at all. The entry point into the implementation is DOMRpcRouter. Glancing over that, it contains some ugliness, but it gets the general outline of the two sides of the contract done.

Digging a bit deeper into the invocation path, you get into the fork at AbstractDOMRpcRoutingTableEntry.invokeRpc(). The RPC invocation path is rather straightforward, but the invocation path for actions is far from simple. Out of two code paths (actions and RPCs) we suddenly have 4, as an action can be invoked without a context reference as if it were an RPC and there is a brief mention of remote rpc connector registering action implementations with an empty context reference … wait … WHAT???!!!

Okay, we seem to have two implementations integrated based on implementation details, without that being supported by a single line in the API contract. The connector referenced is actually sal-remoterpc-connector and is something that is meaningful in clusters. To make some sense of this, we have to go back to 2013 again.

A Tale of Three Routers

From the get go, the MD-SAL architecture was split into two distinct worlds: Binding-Independent (BI, DOM) and Binding-Aware (BA, Binding). This split comes from two competing requirements: type-safety provided by Java for application developers who interact with specific data models and infrastructure services which are independent of data models. The former is supported by interfaces and classes generated from YANG models and generally feels like any code where you deal with DTOs. The latter is supported by an object model similar to XML DOM, where you deal with hierarchical ‘document’ trees and all you have to go by are QNames. For obvious reasons most developers interacting with OpenDaylight have never touched the BI world, even though it underpins pretty much every single feature available in the platform.

A very dated picture of how the system is organized can be found here. It is obvious that the two worlds need to seamlessly interoperate — for example RPCs invoked by one world must be able to be serviced by the other and the caller should be none the wiser. Since RPCs are the equivalent of a method call, this process needs to be as fast as possible, too. That lead to a design, where each world has its own Broker and the two brokers are connected. Invocations within the world would be handled by that world’s broker, foregoing any translation. A very old picture of how an inter-world call would look like can be seen in this diagram.

For RPCs this meant that there were two independent routing tables with re-exports being done from each of them. The idea of an RPC router was generalized in the (now long-forgotten) RpcRouter interface. Within a single node, the Binding and DOM routers would be interconnected. For clustered scenarios, a connector would be used to connect the DOM routers across all nodes. So an inter-node BA RPC request from node A to node B would go through: BA-A -> BI-A -> Connector-A -> Connector-B -> BI-B -> BA-B (and back again). Both the BI and connector speak the same language, hence can communicate without data translation.

The design was simple and effective, but has not quite survived the test of time, most notably the transition to dynamic loading of models in the Karaf container. Model loading impacts data translation services needed to cross the BA/BI barrier, leading to situations where an RPC implementation was available in BA world, but could not yet be exported to the BI world — leading to RPC routing loops, and in case of data store services missing data and deadlocks.

To solve these issues, we have decided to remove the BA/BI split from the implementation and turn the Binding-Aware world into an overlay on top of the Binding-Independent world. This means that all infrastructure services always go through BI, and the Binding RPC Broker was gradually taken behind the barn, there was a muffled sound in 2015, and these days we only have two routers, one hiding behind a connector name.

Blueprint for a New Feature

Probably the most significant pain point identified by new people coming to OpenDaylight is that the technology stack is a snowflake, providing few familiar components, with implementation and documentation being borderline hostile to newcomers. One of such pieces is the Configuration Subsystem (CSS). Driven by invalid YANG and magic XMLs, it is a model-driven service activation, dependency injection and configuration framework built on top of JMX. While it offers the ability to re-wire a running instance in a way which does not break anything half-way through reconfiguration, it is a major pain to get right.

It pre-dates MD-SAL (which offers nicer configuration change interactions) and is utterly slow (because the JMX implementation is horrible). It was also designed to safeguard against operator errors and this is quite contrary to what Karaf’s feature service provides — if you hit feature:uninstall, those services are going down without any safeties whatsoever.

To fix this particular sore spot, one of the decisions from the Beryllium design summit was to extend Blueprint with a few capabilities and start the long journey to OpenDaylight without CSS, where internal wiring would be done in Blueprint and user-visible configuration would be stored in MD-SAL configuration data store. The crash-course page is a very easy read.

You will note that there is support for injecting and publishing RPC implementations — which is a nice feature for developers. Rather than having to deal with registries, I can declare a dependency on an RPC service and have Blueprint activate me when it becomes available like this:

<odl:rpc-service id="fooRpcService" interface="org.opendaylight.app.FooRpcService"/>

I can also publish my bean as an implementation, just with a single declaration, like this:

<bean id="fooRpcService" class="org.opendaylight.app.FooRpcServiceImpl">
  <!-- constructor args -->
</bean>
<odl:rpc-implementation ref="fooRpcService"/>

This is beyond neat, this is awesome.

FooRpcService vs. DOMRpcIdentifier

We have already covered how Binding Aware layer sits on top of the Binding Independent one, but it is not a one-to-one mapping. This comes from the fact that Binding Independent layer is centered around what makes sense in YANG, whereas the Binding Aware layer is centered around what makes sense in Java, including various trade-offs and restrictions coming from them. One such difference is that RPCs do not have individual mappings, i.e. we do not generate an interface class for each RPC, but rather we generate a single interface for all RPC definitions in a particular YANG module. Hence for a model like

module foo {
    rpc first { input { ... } output { ... } }
    rpc second { input { ... } output { ... } }
}

we generate a single FooService interface

public interface FooService {
    Future<FirstOutput> first(FirstInput input);
    Future<FirstOutput> second(SecondInput input);
}

The reasoning behind this is that a particular module’s RPCs (in the broad sense, including actions) will always be implemented by a single OpenDaylight plugin and hence it makes sense to bundle them together.

An unfortunate side-effect of this is that in the Binding Aware layer, both RPCs and actions are packaged in the same interface and it is up to the intermediate layers to sort out the ambiguities. This problem is being addressed in Binding V2, where each action has its own interface, but we have to have a solution which works even in this weird setup.

Fix Some, Break Some

Considering these complexities and gaps in the API contract documentation department, it is not quite surprising that the fix for BUG-3128, while making RPCs work correctly across the cluster had the unfortunate side-effect of breaking blueprint wiring in a downstream project (OpenFlow Plugin). In order to understand why that happened, we need to explore the interactions between DOMRpcRouter, blueprint and sal-remoterpc-connector.

When blueprint sees an <odl:rpc-service/> declaration, it will wire a dependency on the specified RPC (Binding Aware) interface being available in DOMRpcService (which is a facet of DOMRpcRouter). As soon as it sees a registration, it considers the dependency satisfied and proceeds to with the wiring of the component. This is true for LLDP Speaker, too. Note how it declares a dependency on an implementation of PacketProcessingService. Try as you may, you will not find a place where the corresponding <odl:rpc-implementation/> lives. The reason for this is quite simple: this service contains a single action and an implementation is registered when an OpenFlow switch connects to the OpenDaylight instance. So how is it possible this works?

Well, it does not. At least not the way it is intended to work.

What happens is that Blueprint starts listening for an implementation of PacketProcessingService becoming available with an empty context, just as with any old RPC. Except this is an action, so somebody has to register as a global provider for the action, i.e. as being capable to dynamically invoke it based on its content and not being tied to a particular context. That someone is sal-remoterpc-connector, in its current shape an form, which does precisely what is mentioned in that terse comment. It registers itself as a dynamic router for all actions and when a request comes in, it will try to find a remote node which has registered an implementation for the specified in the invocation. That means that unbeknownst to the Blueprint extension, all actions appear to have an implementation — even if there is no component actually providing it — and therefore LLDP Speaker will always activate, just as if that dependency declaration was not there.

The fix to address BUG-3128 performed a simple thing: rather than using blanket registrations, it only propagates registrations observed on other nodes — becoming really a connector rather than a dynamic router. Since no component provides the registration at startup time, blueprint will not see the LLDP Speaker dependency as satisfied, leading to a failure to activate. Unless an OpenFlow switch happens to connect while we are waiting — in that case, activation will go through.

So we are at a fork: we either have blueprint ‘working’, or we have RPC routing in cluster working. Getting both to work at the same time, and actually fixing LLDP Speaker to activate when appropriate, we will obviously have to perform some amount surgery on multiple components.

I will detail what changes are needed to close this little can of worms in my next post, so stay tuned 🙂

 

Róbert Varga

CTO Pantheon Technologies