Jump to: navigation, search


< Interns(Redirected from InternProjects:Main)

Project Ideas

Mentors, pleases submit your Project Proposal Ideas following the template below.
Interns, please review the Intern Project Guidelines before submitting your project proposals.

    • Not all all Mentor or Intern projects will be accepted as we have a limited number of Internships available.
    • General information regarding the application process, payment schedule and eligibility can be found at Linux Foundation Networking Wiki Internship Page. Technical questions about specific Internship projects should be addressed by the Project Mentor. General questions about the Internship Program can be addressed by Casey Cain.
    • Completed project Proposals should be sent to lfn-internship@linuxfoundation.org

Open Projects


  • Title: Provide a short but descriptive title of what the intern project is
  • Description: Provide at least two or three paragraphs describing the task. Include the problem/opportunity in need of effort, as well as a description of the task to fix the problem or realize the opportunity. If there is a probable implementation path... "this will need steps X, Y, and Z to be completed" please describe it. If part of the task is evaluating one or more potential implementation paths and selecting/executing on one of them, please describe the options and the potential paths to be explored.
  • Additional Information: Provide links to bugzilla entries, release-plan notes, and/or other web-references that would be helpful information to potential interns.
  • Desirable Skills: List both the skills needed and the tools to be used. ie. Java programing with working knowledge of OpenStack Neutron and the principals behind SDN, Openflow, and network overlays. Experience with mininet and wireshark will also be very helpful.
  • Expected Outcome: List the deliverable(s) (features/application(s)/report(s) etc.) expected
  • Difficultly: Easy/Medium/Hard
  • Mentors: John Doe <john.doe@notarealemailaddress.com>, Jane Smith <JSmith@alsonotarealaddress.com>
  • Additional Contacts: Identify the IRC channel(s) and mailing list(s) where potential interns can ask questions and further interact with members of OpenDaylight project they would be working with.

Infrastructure Optimization

  • Title: Data-driven cloud infrastructure cost reduction
  • Description: OpenDaylight runs massive Continuous Integration Testing infrastructure using tools like Jenkins and a public cloud provider. OpenDaylight's 2019 budget requires reducing our cloud infrastructure costs by hundreds of thousands of dollars, or by something like 20% of the current usage. To achieve this ambitious goal, we want to leverage a data-driven approach to identify what jobs are most ripe for optimizations. The intern will do data analytics using OpenDaylight's Bitergia data (number of job runs, duration, VM flavor), in conjunction with cloud hosting costs (cost per VM flavor per unit time). They will then work with the relevant OpenDaylight job-owning projects and the ODL Testing/RelEng community to disable jobs, reduce job frequency, or reduce the size of job VMs.
  • Desirable Skills: Experience contributing to Open Source projects, working with Jenkins Jobs Builder, or working with Bitergia/similar.
  • Expected Outcome: Complete analysis of jobs to identify which are most costly. Use resulting data to reduce infra costs as much as possible.
  • Difficultly: Medium
  • Mentors: Daniel Farrell <dfarrell@redhat.com>, ODL Test/RelEng community <integration-dev@lists.opendaylight.org>
  • Additional Contacts: dfarrell07 on IRC in #opendaylight-integration on Freenode

Staffed/Completed Projects

Proposal : Instrumentation of OpenDaylight with Opentracing/Jaeger

  • Title: Instrumentation of OpenDaylight with Opentracing/Jaeger
  • Description: Opentracing is a CNCF project that provides standardized semantics for distributed tracing. Instrumenting OpenDaylight with Opentracing will help developers and users interms of effective debugging and latency detection during deployments. Jaeger implements Opentracing and has rich semantics and recommended for this instrumentation
  • Additional Information:
  • Desirable Skills: Java programming with exposure to microservices architecture
  • Expected Outcome: Jaeger UI should display spans of NetVirt project
  • Difficultly: Medium - High
  • Mentors: Prem Sankar G <prem.sankar.g@ericsson.com> & Michael Vorburger <vorburger@redhat.com>
  • Additional Contacts: #opendaylight-coe #opendaylight-infrautils

Proposal : Enable Cookie Based Flow Deletion for MD-SAL driven OpenFlowPlugin users

  • Title: Enable Cookie Based Flow Deletion for MD-SAL driven OpenFlowPlugin users
  • Description: OpenFlow is a vendor-neutral standard communications interface defined to enable interaction between the control and forwarding layers of an SDN architecture.The OpenFlow plugin project intends to develop a plugin to support implementations of the OpenFlow specification as it develops and evolves. Specifically the project has developed a plugin aiming to support OpenFlow 1.0 and 1.3.x. It can be extended to add support for subsequent OpenFlow specifications. The plugin is based on the Model Driven Service Abstraction Layer (MD-SAL) architecture. All applications who want to program OpenFlow switches, use the MD-SAL Datastore, and OpenFlow plugin listens on the Data change notifications of the same, to program the southbound devices accordingly.

    Due to the inherent limitation imposed by the Datastore, some of the flexibilities provided by OpenFlow specifications are not available for applications who use MD-SAL as front end for OpenFlow programming. One major example is “cookie based flow rule deletion”. As per OpenFlow specification, all flows having the same “cookie” field can be deleted in one shot, using the cookie based flow deletion mechanism. However, all the flow rules which are written to MD-SAL datastore are keyed using a unique “flow-id”, and OpenFlow plugin listens to the deletion of individual flows from the Datastore, and transalates the same as FLOW DELETE requests to the switch. Due to this, the capability of bulk deletion of flows based on a cookie is not available for the applications, even though openflowplugin does expose an RPC for doing the same.

    With this proposal, we aim to develop utilities which can help in cookie based flow deletions, as there are multiple applications which are demanding the same. For eg : Genius project has use-cases where there are a series of flows mapping to the same interface, and when an interface is deleted, all these flows needs to be deleted. If a unique interface-tag can be stamped into the openflow cookie of these flow rules, all the flows can be deleted with just one single openflow command to the switch.

  • Desirable Skills: Java programing with working knowledge of Opendaylight and the principals behind SDN, and Openflow. Experience with mininet and wireshark will also be very helpful.
  • Expected Outcome:
    1. New APIs for cookie based flow deletion
    2. Performance improvements for bulk flow deletions
    3. Implementation of one usecase in Genius service-binding logic
  • Difficultly: Medium
  • Mentors: Faseela K <faseela.k@ericsson.com>, Vishal Thapar <vishal.thapar@ericsson.com>
  • Additional Contacts: #opendaylight-genius, #opendaylight-openflowplugin

Proposal : CSIT for Kubernetes ODL integration

  • Title: CSIT for Kubernetes ODL integration
  • Description: COE(Container Orchestration Engine) project aims at developing a framework for integrating Container Orchestration Engine (like Kuberenetes) and OpenDaylight.For Oxygen, COE is targeting to finish development of Kubernetes CNI Plugin for Opendaylight, and complete netvirt – coe integration, to enable l2 and l3 connectivity for containers.This proposal aims to develop integration tests for the kubernetes ODL integration. The CSIT should bring up a kubernetes master and two kubernetes minions, with the CNI Plugin developed by ODL COE Project.The CSIT should be able to run the ODL watcher developed by ODL COE project, to capture all the northbound events and transform them to ODL northbound REST calls.The CSIT should be able to verify l2 and l3 connectivity for pods on the same node as well as across nodes.
  • Desirable Skills: Java programing with working knowledge of Opendaylight and the principals behind SDN, and Openflow. Experience with kubernetes.
  • Expected Outcome:
    1. New CSIT suite for kubernetes ODL integration with basic test cases
    2. Stretch goal to have a scale CSIT setup
  • Difficultly: Medium
  • Mentors: Faseela K <faseela.k@ericsson.com>, Prem Sankar G <prem.sankar.g@ericsson.com>
  • Additional Contacts: #opendaylight-coe, #opendaylight-netvirt

Proposal : Enable building OpenDaylight projects with Gradle instead of Maven

  • Title: Enable building OpenDaylight projects with Gradle instead of Maven
  • Description: The build system currently used in OpenDaylight to go from our sources git.opendaylight.org to our binary artifacts including JAR files and Karaf distributions available on nexus.opendaylight.org is the venerable Apache Maven build tool. The goal of this project is to gradually build some of OpenDaylight's projects with Gradle instead of Maven. This will open the door to working incremental builds with use of Gradle's distributed build cache, leading to blazing fast local builds, and could fundamentally change the way OpenDaylight is currently built on our integration servers. This eventual full goal may not be reached as part of this project, but it would develop some of the pieces required to get there.
  • Desirable Skills: You need to have proven prior experience in the area of build tools for Java based projects; please include links to publicly viewable open source contributions related to any work you may have previously done related to tools such as Ant, Ivy, Maven, Gradle, Bazel, Buck or other. You'll need to self train to come up to speed with Gradle, not just simple usage but custom build scripts and plugins. You do not need any experience or skill with SDN related topics.
  • Expected Outcome:
    • simple POC of project infrautils converted from Maven to Gradle, without Karaf parts (no YANG code generation), see https://github.com/opendaylight/infrautils/compare/master...vorburger:gradle
    • full POC of above, including equivalents of all currently used Maven plugins, except Karaf
    • implement https://jira.opendaylight.org/browse/YANGTOOLS-746
    • write a new Gradle Plugin equivalent to our yangtools/yang/yang-maven-plugin
    • POC project genius converted from Maven to Gradle, without Karaf parts, but with YANG code generation
    • explore Karaf Gradle related space; build POC if any existing equivalent plugins, contribute to them to make them suitable for us, or start a new project for such plugins
  • Difficultly: Hard
  • Mentors: Michael Vorburger <vorburger@redhat.com>
  • Additional Contacts: #opendaylight-infrautils

Proposal : Jenkins Job Builder - Improve Jenkins Plugins Support

  • Title: Enhance JJB support for Jenkins Plugins used by OpenDaylight and other LF projects
  • Description: OpenDaylight uses Jenkins Job Builder to manage Jenkins jobs. This project's purpose is to evaluate all plugins used by OpenDaylight are up to date in regards to JJB support. A successful student will be expected to:
    • Evaluate Jenkins Plugins used by OpenDaylight for level of current support
    • Enhance JJB with new features needed by both OpenDaylight community as well as upstream community
    • Participate in code review in JJB as well as OpenDaylight's releng/builder projects
    • Reach out to the community for ideas and opinions on new features
    • Actively participate with the community in IRC and mailing lists
  • Additional Information:
  • Desirable Skills:
    • Python
  • Expected Outcome: JJB Support for Jenkins plugins should be improved overall. A successful student will provide a status report at the end of the internship detailing all of the changes made to JJB during their term.
  • Difficultly: Easy
  • Mentors: Anil Belur <abelur@linux.com>, Andrew Grimberg <agrimberg@linuxfoundation.org>
  • Additional Contacts:
    • dev@lists.opendaylight.org with topic [releng]
    • #lf-releng @ irc.freenode.net
    • #openstack-jjb @ irc.freenode.net

* Status: Intern shortlisted for July 2018 start date.

Proposal : Test Dashboard For OpenDaylight

  • Title: Test Dashboard For OpenDaylight
  • Description: Today we have many tests in OpenDaylight (sanity*, feature, performance, scalability, longevity) with different trigger (after change, release creation, daily, weekly), duration (10 mins to 23 hours) and even result output (PASS/FAIL, perf/scale numbers). This is cool but kind of useless if we do not have a place where users can easily browse and check the test results. We already created some framework to collect test results and generate a REST request to update an elasticseach database that later can be used to display results in kibana . On top of that we have elk based opendaylight bitergia (http://opendaylight.biterg.io/) that could be leveraged to display test results. The expected work would be something like:
    • Evaluate possible solutions to display test results: bitergia is prefered, otherwise stand-alone ELK server.
    • Set up automation (shell/python) to create dashboards and feed the test data to them.
    • Proper document everything so it can be easier maintained.
  • Additional Information:
  • Desirable Skills: Jenkins, Bash scripts, Python, Elasticsearch (ELK) framework.
  • Expected Outcome:
    • Test reports and dashboards so that users can easily browse and check test results.
  • Difficultly: Medium
  • Mentors: Luis Gomez (primary) <ecelgp@gmail.com> IRC: LuisGomez, also assisting: Thanh Ha
  • Additional Contacts: Integration group <integration-dev@lists.opendaylight.org>

Proposal : Wiki Cleanup / Update

  • Title: Update wiki and clean up outdated content
  • Description: The wiki is currently full of outdated information. This project will encompass the update of the wiki as well as writing some documentation for developers to easily update or maintain their project templates.
    • Remove outdated content, update important pages.
    • Work with Project Team Leads to update Project Facts.
    • Update general format.
    • Develop a guide for Projects to maintain / update project information.
    • Update Project Dependency graph.
  • Desirable Skills: Experience with Mediawiki. Good socializing skills. Understanding of Project Development.
  • Expected Outcome: Clean wiki with updated project templates. Guide for developers to maintain project templates.
  • Difficultly: Easy
  • Mentors: Casey Cain <ccain@linuxfoundation.org> , Daniel Farrell <dfarrell@redhat.com>
  • Additional Contacts: CaseyLF on IRC, dfarrell on IRC docs@lists.opendaylight.org

Proposal : Feature Parity Puppet:Ansible

  • Title: Achieve feature ansible-opendaylight feature parity with puppet-opendaylight
  • Description: OpenDaylight supports two configuration management tooling stacks - puppet-opendaylight (historically came first) and ansible-opendaylight (likely future direction). There are features in puppet-opendaylight that aren't supported in ansible-opendaylight. The idea of this internship is to port those features to ansible-opendaylight so that it has feature parity with puppet-opendaylight. Adding test coverage for both ansible-opendaylight and puppet-opendaylight may additionally be covered by this project.
  • Desirable Skills: Independent, self-driven worker capable of putting out more cycles of good work than the mentor puts in. Linux skills. Experience contributing to Open Source projects. Possibly experience with configuration management tools like Ansible.
  • Expected Outcome: Feature parity between ansible-opendaylight and puppet-opendaylight. Additional test coverage for both.
  • Difficultly: Hard
  • Mentors: Daniel Farrell <dfarrell@redhat.com>
  • Additional Contacts: dfarrell07 on IRC, integration-dev@lists.opendaylight.org