Skip to end of metadata
Go to start of metadata

Internship Projects/Mentors


ONAP Web Based Architecture Navigation Solution






Already familiar with things like PHP, JSON, HTML and CSS? Do you want to learn some of the non-technical skills needed to effectively collaborate in an opensource project as more than just a code contributor?  If so this could be the perfect internship for you.

ONAP, the Open Network Automation Platform has transformed the telecommunications industry forever and is a key component of the 5G story. But don't worry, this internship does not require any background or knowledge of the network or telecommunications industry.  It is instead about an experimental web application that provides high value when viewed in one context, causes redundancy when viewed from another perspective and a mutually agreed upon need for a solution to the same critical shared problem.

At a high level ONAP is a complex architecture with a myriad of interdependencies and relationships between ONAP's components, other open source projects and industry standard organizations.  One of the first things a new user may do when investigating ONAP is look at the architecture diagram and then go searching for the appropriate documentation set in relationship to the picture.  The feedback we've received is that actually finding the correct documentation is often time consuming and confusing. Making the correct documentation easier to find is the, "mutually agreed upon need" part previously mentioned.

ONAP documentation takes on 2 forms. First (and the most problematic) is our development documentation on This is highly uncontrolled and gets obsolete rapidly.  The second and more important part is the official documentation at which is all curated content. The latter is the realm of ONAP's Documentation project, a hard working group of folks that are responsible for defining the guidelines and tooling for documentation handling across all ONAP projects. They also help ensure that when we cut a new release the documentation is in the best possible state. They don't write the documentation per-se, but they make sure that the structure, look and feel and similar things are aligned and as complete as possible.

ONAP's Architecture Subcommittee also works across all of our projects. This group is focused on how the technical pieces of ONAP all fit work together. The ONAP Architecture Navigator (ArchNav for short) is a web based Proof of Concept (PoC) developed by the Subcommittee for the purpose of quickly moving around areas of ONAP documentation via the architecture diagram specific to each release. This allows people to find information in a manner that is based upon a visual representation of the architecture itself rather than being a more menu driven model. 

There were discussions underway to transition ArchNav out of the lab an into a production environment for the Architecture Subcommittee. That is a pretty straight forward technical effort for anyone with the "Must Have" skills listed below.

The Doc team also wants to pursue ArchNav like functionality however they feel there is no need for it to be a separate application. Instead they believe the same functionality can be implemented directly in ReadtheDocs which is the platform we use for our official documentation.   

So what is the right thing to do? 

Welcome to the world of project management and collaboration in open source. That's what we do every day at the Linux Foundation and if you that's the biggest thing you will learn with this internship. (smile)   You will be working with a truly international team which includes the Doc project team,  the Architecture Subcommittee and others from the ONAP community to coordinate the correct solution to our shared needs.   You won't be making the decisions or figuring out what the best solution is yourself, but you will be an equal partner in the process as the person helping to coordinate all of that effort. 

Additional Information

Learning Objectives

  • Considerations and requirements for a production grade web based application
  • Processes related to project management in an opensource community

Expected Outcome

  • Open Source Project Management:  Consensus is reached on the most practical approach for the community::
    1. ArchNav will not be migrated and a solution will be implemented in ReadTheDocs infrastructure.
    2. ArchNav will be migrated to infrastructure managed by the Linux Foundation as a shared resource for the Doc Team and Subcommittee
    3. ArchNav will be migrated to infrastructure managed by the Linux Foundation as a stand-alone solution for the Subcommittee
  • Technical:  Regardless of the three possible project management outcomes above there will be tooling and scripting required throughout the course of this internship either as proof points, implementation and deployment or migration tasks to deliver the agreed upon solution.

Relation to LF Networking 


Education Level


  • Must Have: Standard web development concepts and practices, JSON, PHP, HTML, CSS comfortable using Linux and script writing
  • Extra Points: Rich Text Format, ReadTheDocs, Confluence, Jira, Git, GitHub, Gerrit and knowledge of the Apache2 webserver, 
  • Level-up:  Multi-participant project management or coordination

Future plans

The intern can stay engaged as a Committer or code contributor to the project if desired as updates to the code will be required for each ONAP release.

Preferred Hours and Length of Internship


Mentor(s) Names and Contact Info

Technical: Chaker Al-Hakim Architecture Subcommittee Chair, Futurewei
Technical: Thomas Kulik, Doc Project Technical Lead,  Deutsche Telekom
Project Management: Kenny Paul, Technical Program Manager, The Linux Foundation


  1. OK, with the assumption the mentors will sepcify more specific targets and tasks for the mentee in context of studying ArchNav migration to RTD.

    1. Yes. That's how it will work.

  2. OK with the assumption that you have reviewed my comment - Re: [onap-discuss] Revised Intern proposal

  3. I am not sure if we all "mutually agreed upon need" for a solution outside of DevWiki or RTD, but with the ArchNav Chaker adresses issues in the current platforms and their content/structure which definitively have to be solved. I am also unsure about, if it is possible to "implement the same functionality directly (and only) in RTD" - but let's see what is possible and if it maybe makes sense to extend functionality of the Wiki or RTD. Also the discussed restart of the DevWiki can possibly help to fix some of the issues.
    We have dedicated the upcoming doc weekly meeting (April, 15th) to the ArchNav and the required exchange. I am looking forward for a constructive discussion.

    1. Fwiw, I did not read "mutually agreed upon need for a solution" was about anything outside DevWiki or RTD. I read it to say:

      "It <i.e. the internship> is instead about ... a mutually agreed upon need for a solution to the same critical shared problem." And this "shared problem" I understood to be what you write "... issues ... which definitively have to be solved".

      With that looks like we're on the same page with the starting point, and further details then to be agreed on the actual task description of the intern.

      1. I am sorry if i have misunderstood it. Can you please provide a link to the description of the WIKI taskforce? That would help also to complete the picture.

        1. I dare not to say I've understood it right, just wanted to share what my parser produced from the description (wink)

          If you are referring with "WIKI taskforce" to what was announced/agreed in ONAP TSC April 8th:
          "Wiki 2.0 - New Task Force led by Timo Perala, Ranny Haiby. Goal: Redefine the structure of the ONAP wiki, to identify the relevant pages, to create onboarding for newbies, etc."
          I'm afraid there's not much more on it yet available that could be shared.