Blog

We kicked off our intern program last summer and are pleased to have  welcomed an amazing group of young talent! They work directly with the community and receive hands-on development experience in NFV. Each intern works closely with an active OPNFV developer as their mentor on a project that suited interest and community need. This blog series aims to showcase these interns and the projects they work on, the mentors who are helping with their professional development, and their experience working in an open source community to help  accelerate NFV.

About Rohit (in his own words):
I am a fourth-year undergraduate student at the International Institute of Information Technology in Hyderabad, India. My interests are in distributing systems and networking. In my free time, I like to explore new things as well as new places and I really love to play badminton, football and obviously Counter Strike GO.     

How did you hear about OPNFV and what got you interested in this internship?
I was an OpenDaylight intern and was  able to attend the OpenDaylight Summit  in Seattle last year. That is where I learned about OPNFV and its internship program; I found an OPNFV project similar to what I was doing with OpenDaylight and it’s going very well so far! I am very glad to be participating in this internship.

Can you talk about your experience working on an open source project? Any previous experiences you can share or key learnings from working on OPNFV so far?     
Working with an open source project is a wonderful experience indeed. I’ve been able to learn about new technologies. Working with open source projects is a great opportunity to write  and contribute to the creation of industry standards programs. I am fortunate to have this experience when in college; in my both internships, community members have been very encouraging and that has  boosted me up many times and empowered me to do more work. 🙂

What’s the best thing you’ve learned from your internship?           
The best thing I have learned from this internship is how to effectively communicate and discuss the pros and cons of a solution among the community, and then feeling empowered to go ahead and move forward with a solution. Being passionate and working hard are two big takeaways for me.

Who is  your mentor and what’s the experience been like?  
My mentor is Serena Feng and she is really cool. We not only talk about the code, but we chit chat about the differences in our cultures (she is Chinese) and also we agree on many common aspects. I ping her a lot in IRC and she never gets angry and clears my doubts very patiently. I am glad to have a mentor like her.

What’s your advice to other aspiring open source folks out there?
There are many open source projects in the world. Just ping in IRC or send an email expressing your interest in a project and there will be many replies! Open source communities are very helpful, and always willing to address questions or talk through issues.  It is a great opportunity to contribute to tech and can bring immense satisfaction.

What gets you jazzed to work with open source? (e.g., listening to music, drinking coffee, chatting in IRC, etc.)?
Chatting in IRC, especially using irssi. I love command line, and irssi doesn’t have any GUI. The perl scripts you write to get a notification when your mentor comes online. Code review is another awesome thing which I really like…getting +2 …being merged. 😛  (And obviously sometimes -1 :/  )

Being in open source allows you to work from anywhere in the world and interact with lots of different people. What have you found most surprising about the open source developer community?
Yes, interaction with lots of different people is definitely a new experience. It actually helps me learn about different work cultures and different ways of approaching solutions, which broadens one’s knowledge. But frankly, I find it very difficult that everyone is not online at one time. I sometimes have to wait a whole day to get a reply 😛

What do you want to do next? What is your dream job?
I don’t have a dream job, per se. But I would like to work more on distributed systems and the networking domain. In general, I love taking on challenging work, like designing new algorithms/architecture stuff.

By Brady Johnson (Ericsson) and Prithiv Mohan (Intel)

OPNFV recently had a chance to participate in the first ETSI NFV Plugtests, held January 23-February 3 in Madrid, Spain. As the first-ever ETSI NFV Plugtests, the goal of the event was a coming together of MANO, VNF and NFV platform (VIM & NFVi) providers to perform ETSI NFV interoperability testing among different vendors and open source providers.

Together with Prithiv from Intel, Ericsson colleagues Juanma Fernandez and Juan Vidal, we were able to represent two OPNFV pods (one indirectly OpenDaylight), which was one of four supporting open source projects, as an NFV platform. Ericsson provided a virtualized OPNFV Service Function Chaining (SFC) Colorado deployment using the Fuel installer. This deployment used an OpenDaylight (Boron) SDN controller as a Neutron back-end.  Intel similarly brought in an OPNFV Colorado release environment with OpenStack Mitaka managed by an Apex installer. In Intel’s setup, OpenStack’s Neutron was used as the SDN controller.

Ericsson were pleased to report that they executed 18 successful, approved test sessions with OPNFV in just under 10 days and Intel were pleased to report 14. (It should be noted that, for a test session report to be “approved,” it needed to be performed by a MANO provider with a VNF on a particular VIM & NFVi. All three parties—the MANO, VNF and VIM & NFVI providers—must approve the report to merit successful completion.) The OPNFV test sessions run by Ericsson included five different MANO providers and 11 different VNF providers. Those run by Intel included six MANO vendors and 12 VNF vendors.

The deployments consisted of:

• OPNFV Colorado 3.0 with the Fuel installer for Ericsson. OPNFV Colorado 3.0 with the Apex installer for Intel.
• Ericsson’s deployment was a virtual deployment with one controller and three computes hosted in the Ericsson Pharos lab. Intel’s environment consisted of five nodes setup with two compute nodes and three controller nodes.
• ODL Boron SR2 was used as the Neutron backend for all networking for the Ericsson setup and OpenStack’s Neutron was used in the Intel platform.
• ODL Netvirt was the Neutron implementation used for Ericsson.

Ericsson is very happy with the outcome of the testing completed during the event, clearly highlighting and demonstrating the value of OPNFV community efforts in NFV.  We are eager to engage further in future Plugtests and similar events to address additional areas we were unable to dive into during these two weeks. For example, there were two additional tests focused on specific hardware capabilities that we weren’t able to execute due to incompatibilities of our virtualized system, and we attempted to run an OPNFV SFC deployment with one more VNF but did not have the time. In the future, we will invest further into establishing a longer pre-testing phase allowing us to prepare the proper configuration, any needed workarounds, and have additional discussions with VNF vendors supporting SFC.

Intel had very successful Plugtests as well. Each test session was done with one MANO vendor and one or two VNF vendors at the same time.  The MANO provider changed every day and the test sessions continued with a different set of VNF vendors. The Intel OPNFV-based environment was so stable that at one point during the busy schedule, there were four MANO solutions and five VNF providers on-boarded at the same time and running tests in parallel.

All in all, it was a successful 10 days and we’re very happy with what was accomplished. This has been a great achievement for the OPNFV project, since it demonstrates maturity of the OPNFV platform, which is now ready for complex deployments. Moreover, it is a clear demonstration that open source MANO projects are ready to integrate with OPNFV, although there is still work to be done when it comes to more advanced use cases such as SFC. Additionally, Ericsson was approached by several VNF providers who asked for help with side testing –a testament to our streamlined process.

A final thought: as these interoperability tests are complementary to OPNFV integration tests conducted during our own OPNFV Plugfests, there’s an even more seamless opportunity for OPNFV to be involved in future ETSI Plugtests.

A special thank you to the extended Intel and Ericsson teams representing OPNFV: Adrian Hoban, Jack Morgan, Trevor Cooper, Ross Brattain and Sibai Li from Intel; and Juan Vidal, Juanma Fernandez, Nikolas Hermanns, Fatih Degirmenci, Jose Lausuch, Harshad Tanna, and Ernest Bayha from Ericsson.

Stay tuned for more information on OPNFV’s evolving testing efforts.

We kicked off our intern program a few months back and are pleased to welcome our first group of OPNFV interns! They work directly with the community and receive hands-on development experience in NFV. Each intern works closely with an active OPNFV developer as their mentor on a project that suited interest and community need. This blog series aims to showcase these interns and the projects they work on, the mentors who are helping with their professional development, and their experience working in an open source community to help  accelerate NFV.

About Shubham (in his own words):
I’m a senior year undergrad at IIIT Hyderabad, India. I’m working on the Ontology of the Indian Patent System, under Professors Navjyoti Singh and Snehal Awate of the Indian School of Business on predicting the premium value of stock in merger scenarios.

I’m hugely fascinated by Yanni and his music. I hope someday, whatever I’m into gives me the engagement, vigor and passion about life and work as his music does to him and so many others like me.    

How did you hear about OPNFV and what got you interested in this internship?
I heard about OPNFV from a friend who is also interning with the project. A major reason for me jumping into OPNFV is the long-term value this platform can create for the industry. It’s a huge opportunity to be a part of a project that, in near future, has the potential to change the methods of traditional networking domains.

Can you talk about your experience working on an open source project? Any previous experiences you can share or key learnings from working on OPNFV so far?
Prior to OPNFV, I had contributed to a few open source projects as part of my attempt at Google Summer of Code. However, this is my first mainstream and long- term work with open source.  

A key learning following the team mails and discussions lists, is the amazing ability of developers scattered in different parts of the world to meaningfully engage and leverage each other’s skillsets to build such a radical technology as OPNFV.

What’s the best thing you’ve learned from your internship?
The best thing I’ve learned is how to communicate unambiguously. When I initially started, I spent quite a bit of time ensuring that everyone was on the same page. Putting forth your ideas without having an iota of assumptions was a major skill to learn. There are so many points which we take for granted as understood. When communicating with teams from different parts of the world, each working on a different aspect of the project, it is necessary to be able to explain ideas such that there is no scope for ambiguity.

This isn’t just a project skill; it’s also a valuable interpersonal skill needed to work in a global, virtual environment. To be effective, it is important that the person is able to grasp the context of what you’re communicating and not just the  content.

Who is  your mentor and what’s the experience been like?
My primary mentor is Sofia Wallin. Trevor Bramwell and Christopher Price are my co-mentors. It’s been great working with them. Each of them are very understanding and have very graciously responded to all my questions and corrected my mistakes. My training literally started with Trevor telling me how to post commit messages. It’s wonderful to be learning about the community and the platform from everyone on the team. In addition, Sofia’s leaderships skills are inspiring; her diligence, patience and conduct makes me strive to do better on the project.

What’s your advice to other aspiring open source folks out there?
Just jump in. Pick up whatever you don’t know. There is never an “ideal” time.

What gets you jazzed to work with open source? (e.g., listening to music, drinking coffee, chatting in IRC, etc.)?
Definitely music.

What do you want to do next? What is your dream job?
After this internship, I’ll be focusing on finishing my research. I’m still figuring out what my dream job is. Anything done long enough starts becoming a drudgery. I’d like to keep my mind (and maybe my job) moving with opportunities and fascinations at different stages of my career. I’d be keen to find transdisciplinary opportunities pivoted around Software engineering roles but not limited to them.

By Lincoln Lavoie, senior engineer, Broadband Technologies, University of New Hampshire InterOperability Laboratory (UNH-IOL)

Wrapping up the OPNFV Colorado release work in 2016, the OPNFV Plugfest and co-located Hackfest in December brought together 70 participants from 23 different organizations. The international group, traveling in from Asia, Europe, and North America, converged at the UNH InterOperability Laboratory (UNH-IOL) in Durham, NH for a full week of activities.  Fueled by coffee, snacks, fancy chocolates (someone brought from afar), and more coffee, participants spent the week running tests and various deployment scenarios, working with on- and off-site hardware and the development teams. The testing focused on two key areas: 1) deployment testing with different hardware/software combinations and 2) Open-O integration with OPNFV. There were also some Hackfest development and testing efforts: 1) multi-site deployment and 2) enabling OPNFV Doctor. In all cases, teams of developers were able to identify bugs or enhancements to complete the task at hand, with the identified issues being reported as part of the Plugfest’s white paper. Rest assured, JIRA tickets have also been created and worked for each item as well!

Deployment testing combined on-site hardware resources from Huawei, Lenovo, and Nokia, and off-site resources from ENEA, Huawei, Intel, and NEC.  The Lenovo and Nokia hardware based on the Open Compute Project (OCP) hardware designs, representing  the first time this type of hardware had been tested at an OPNFV event (open source running on open hardware).  While the OCP hardware isn’t specifically designed for OPNFV, it’s high density designs, with dedicated high-speed network interfaces, the designs align very well with the requirements for the NFV architectures. The teams worked together to deploy one or more of the OPNFV installers/scenarios on each set of hardware, and once completed, used OPNFV testing tools, such as Functest, Qtip, and StorePerf to test the NFV platform (refer to the white paper for a full list of tested installer/scenarios and hardware combinations).

While the Plugfest participants were busy, Hackfest participants were no slackers either. The event schedules were packed, with project teams meeting throughout the week. Some of the “full room” discussions included the Colorado release retrospective, finalization of the Pharos pod descriptor file, and the cross community CI activities–specifically with the OpenDaylight and Open-O projects.

Looking to the Spring (and warmer weather), the date and location of the next OPNFV Plugfest & Hackfest have just been announced: April 24-28, in Paris, France at the Orange campus.  With all the work completed at this event, the bar has been set high, but maybe we can create some additional motivation during the Plugfest with the promise of French wine at the end of the day. We hope to see many of you in Paris. In the meantime, please check out the OPNFV Plugfest Report: Lessons and Results from the Second OPNFV Plugfest (December 2016) and let us know if you have any feedback, questions, or ideas.

We kicked off our intern program a few months back and are pleased to welcome our first group of OPNFV interns! They work directly with the community and receive hands-on development experience in NFV. Each intern works closely with an active OPNFV developer as their mentor on a project that suited interest and community need. This blog series aims to showcase these interns and the projects they work on, the mentors who are helping with their professional development, and their experience working in an open source community to help accelerate NFV.

About Akshita (in her own words):
I am Akshita Jha, currently in my final year of a dual-degree course of B. Tech in Computer Science and MS by Research in Computational Linguistics from the International Institute of Information Technology, Hyderabad (IIIT-H), India. I love development and contributing to open source projects. I am also interested in NFV, Machine Learning and Artificial Intelligence. In my free time, I like to paint and love trying out different cuisines.

Currently, I am working on ODL –>OPNFV integration for better automating package builds, adding .deb support to OpenDaylight’s configuration management tooling (Ansible, Puppet) and pre-built images (Docker, Vagrant) and working with OPNFV installers to help them use upstream tooling (upstream/improve JOID’s ODL JuJu Charms, help Compass use Ansible role with .deb/RPMs).

How did you hear about OPNFV and what got you interested in this internship?
I first heard about OPNFV during my internship with OpenDaylight in Summer 2016. As an ODL intern, I worked on creating a .deb package for OpenDaylight. One of the best things about this project was that it enabled OPNFV installers that support non-CentOS scenarios (JOID, Compass) to consume ODL pretty easily, using upstream tools. I attended OpenDaylight Summit 2016 in Seattle, WA where I got a chance to interact with inspiring people from the OPNFV community. We spoke about the scope of ODL–>OPNFV integration and that resulted in this internship.

Can you talk about your experience working on an open source project? Any previous experiences you can share or key learnings from working on OPNFV so far?
I had the opportunity to work with Debian as a Google Summer Of Code intern in 2015 and as I have previously mentioned, as an OpenDaylight intern in 2016. Most of my technological knowledge is due to my experience with open source projects. I feel the best way to learn a technology is to contribute to an open source project that uses that technology. The constructive feedback that you receive on your code from the community helps a lot. In the beginning, I remember being miffed about receiving continuous -1’s on a gerrit code-review! I now understand that the willingness to take that criticism and improve the code is what makes you a better developer. It’s about sharing and learning through collaboration.

Another, amazing thing about an open source project is that you can see the real-life impact of your work. What makes it even more appealing is that the entire source code is ‘open’. Moreover, you are aware of the entire pipeline of the product. And in case of any confusion, you can always reach out to the community for help.

What’s the best thing you’ve learned from your internship?
I have learned a lot from my internship. I was relatively new to many concepts and I found myself asking, more than once. ‘am I good enough?’. But over time I realised that it’s a mental block more than anything else. One step at a time. One small task, one small bug at a time and voila! before you know it, you have the solution to the problem you thought was impossible to solve. I think this is the best thing I learned during my internship.

Who is  your mentor and what’s the experience been like?
My mentor for ODL–>OPNFV integration project is Daniel Farrell. He is the Project Technical Lead of OpenDaylight Integration/Packaging, committer to Integration/Test, OpenDaylight TSC member, PTL of OPNFV’s Controller Performance Testing project (Cperf) and committer to the CentOS NFV SIG. My experience with him has been wonderful. From the very beginning, Daniel has been very welcoming. He encouraged me to be proactive and make self-directed choices. He is extremely patient, very helpful and gives excellent in-depth code reviews. I’ve learned a lot from him, be it writing good commit messages or working with complex modules of  Puppet, Ansible or Vagrant. He’s someone I look up to. I don’t think I could have asked for a better mentor.

What’s your advice to other aspiring open source folks out there?
I was encouraged by my mentor, Daniel Farrell, to make docs contributions to get started in the open source community. I suggest the same. As new contributors read the docs, you see what’s unclear, what’s missing and what’s wrong. That’s the ideal time to update the docs for the next person.

The codebase may seem intimidating at first and you might think that you are not making any ‘real’ contribution. But trust me, you are. My first ever open source patch was to make a python codebase pep8 compliant! Small contributions help in getting a feel of the larger project.

Also, don’t get bogged down by looking at the required skills for the project. It’s okay if you meet only 51% of the listed requirements. Join the mailing list. Ask questions. Don’t ask to ask. And learn as you proceed.

Open source is a very diverse world. The community wants you to succeed and being self-motivated and proactive really helps. If you are determined to learn, then you are in the right place.

What gets you jazzed to work with open source? (e.g., listening to music, drinking coffee, chatting in IRC, etc.)?
Drinking green tea! Trying to adopt a healthier lifestyle. 🙂

Being in open source allows you to work from anywhere in the world and interact with lots of different people. What have you found most surprising about the open source developer community?
Exactly that! It’s amazing how diverse people from completely different time zones come together to work on one project. New developers join. The community grows. The uniting factor here is the interest and the motivation. The dynamism of the open source world blows my mind. No matter what your interests are, no matter how varied your skill set, you will still be an important part of this thriving community.

What do you want to do next? What is your dream job?
Actually, I am still trying to figure this out. I love the work that I am currently doing in SDN and NFV. Side by side, I am also trying my hand at certain fields that have piqued my interest for quite some time such as NLP and psychology. Let’s see!

We kicked off our intern program earlier this year and are pleased to welcome our very first OPNFV interns! They work directly with the community and receive hands-on development experience in NFV. Each intern works closely with an active OPNFV developer as their mentor on a project that suited interest and community need. This blog series aims to showcase these interns and the projects they work on, the mentors who are helping with their professional development, and their experience working in an open source community to help  accelerate NFV.

About Zahra Jahedi:

Zahra is a PhD student at System and Computer Engineering Department of Carleton University. She worked as an intern with OPNFV last summer. During her internship she worked on the JOID project. She deployed Juju on top of MAAS. She deployed different VNFs from Juju charm store. She was involved in automating the Juju deployment on top of Openstack. She is now working on her PhD thesis which is about NFV in wireless networks and looking forward to be involved in the open source community.

In Her Own Words

We had a chance to chat with Zahra during LinuxCon earlier this year and caught it on video.  Hear from Zahra directly about how she got started, her work on the Pharos labs to deploy Juju and MAAS, and what it’s like to work in the OPNFV community.

Interested in becoming an OPNFV intern or mentoring an OPNFV intern? Please contact internship@opnfv.org.  More details on the OPNFV Internship Program, including specific projects and current intern opportunities, are available on the OPNFV Wiki.

By Tapio Tallgren

We’ve just issued the latest iteration of the OPNFV platform, OPNFV Colorado 3.0. While the initial Colorado 1.0 release was a major milestone, the work on Colorado did not stop at the release. Colorado 3.0 has 19 scenarios, including one new one. There are updated installation images for three installers, including updates for both x86 and ARM. And as with earlier versions, Colorado 3.0 has a choice of SDN controllers, different virtual switches for fast packet processing, and for using network features such as Service Function Chaining (SFC) and BGPVPN.

Releasing Colorado 3.0 involved a lot more than just copying the Colorado 1.0 installer images and documentation to the server. One of the biggest opportunities these update releases provide is the opportunity for different OPNFV projects to implement bug fixes (both from the upstream projects and to enhance their own code base). However, what might seem like a “simple” change in one line of code is actually much more complicated; it involves testing of that code with different installers and with different combinations of projects.

To get an idea of the complexity of what goes into each release–whether a milestone release or a point release–visit this page on the OPNFV wiki. It lists all the different scenarios and their testing status for the Colorado 3.0 release. Each combination of an installer and related feature project is as a “scenario” that needs to be tested. There are currently seven different testing projects that test different aspects of the scenario across two different hardware architectures (Intel x86 and ARM).

To tame this complexity, considerable focus has gone into OPNFV’s continuous integration (CI) system to make running theses tests and reporting the results much easier. While there is still work to be done, updated results can be found here. What you’ll find is that Colorado 3.0 presents an even more solid foundation for NFV applications and services. We encourage the community to start working with Colorado 3.0 and share any feedback on the OPNFV Users mailing list.

Meanwhile, we’re hard at work on the next major OPNFV release, Danube, which is expected in 1H2017. More about that later! On behalf of the TSC, I wish you happy holidays and a happy new year.

Mark Collier, COO of the OpenStack Foundation, creating a network outage during a keynote demo at the OpenStack Summit in Barcelona.

This blog post first appeared on Linux.com and is also available at OpenStack Superuser.

We’ve all been the victim of a dropped mobile phone call and know how frustrating it can be. However, virtualized networks provide network operators with powerful tools to detect and recover from network disruptions, or “faults,” that can drop calls for thousands of subscribers simultaneously. The Open Platform for Network Functions Virtualization (OPNFV) project together with OpenStack have developed features in software that add resiliency to mobile networks and enable them to recover from network and other outages.

At the recent OpenStack Summit in Barcelona, both groups demonstrated how new technologies in NFV can help minimize network disruptions. During the keynotes, technical leads from the OPNFV Doctor Project and OpenStack Vitrage project conducted a phone call using a 4G mobile system running on top of OpenStack. The mobile call continued without disruption even after a dramatic cutting of network cables. (You can watch the short demo in its entirety below.)

To get the skinny on how the technology works and what it took to pull off such a compelling demo, we sat down with folks involved with OPNFV, OpenStack and the Doctor project, including Ifat Afek (System Architect at Nokia Cloudband), Carlos Goncalves (Software Specialist at NEC), Ryota Mibu (Assistant Manager at NEC), and Ildiko Vancsa (Ecosystem Technical Lead at OpenStack Foundation).

OPNFV: Can you give an overview of the demo you did at OpenStack Summit?

OPNFV/OpenStack demo team: We performed two live mobile calls from stage and both were interrupted. The first call dropped when Mark Collier (COO at OpenStack Foundation) removed two cables from the servers powering the mobile system for the calls. After this failed call, Ryota Mibu enabled the OPNFV Doctor features and the teams made another call. During the second call, Mark cut the network cables with giant scissors, but this time the call continued without disruption.

The demo leverages OpenStack as the base for a 4G mobile system equipped with the functionality to perform a smooth failover in case of faults in the system (in a process called “Fault Management”). OpenStack laid the foundation for the cloud-based mobile platform and OPNFV—via the Doctor Fault Management project—filled the existing feature gaps and provided system integration. While we successfully showed how OpenStack operates in an NFV/Telecom environment, the demo was also an example of the fruitful collaboration between the OpenStack and OPNFV communities as development of the new features and additions were driven through Doctor “upstream” into OpenStack.

OPNFV: Can you talk a little more about fault management and why it’s important?

Demo team: There is no system without faults, errors, and failures, even in the cloud. Fault management is a component that allows operations teams to monitor, detect, isolate and automate the recovery of faults. With an efficient fault management system, countermeasures can negate the effects of any deployment faults, avoiding bad user experiences or violation of service-level agreements (SLAs).

To put this in perspective, think about the impact to network services during natural disasters or other emergencies. According to a report by NTT DOCOMO, the largest mobile phone operator in Japan, thousands of antennas and other infrastructure equipment went out of service as a result of the magnitude 9.0 earthquake and tsunami in March of 2011. The consequences, as we all know, were devastating. Millions of mobile subscribers were disconnected from the cellular network, unable to make emergency calls or check in with loved ones.

Service continuity of virtualized platforms has to be equally addressed. The features enabled by OPNFV and OpenStack add value toward helping operators quickly recover from small to large-scale faults, ultimately keeping our societies connected in times of need.

OPNFV: How can organizations implement Doctor’s Fault Management solution in their networks?

Demo team: While not standalone software that can be downloaded and installed directly, the core Doctor framework relies on OpenStack components. Any organization deploying recent versions of OpenStack (from Liberty onward) will have Doctor-prescribed enhancements already available out-of-the-box with little to no configuration. In other words, Doctor is now a part of OpenStack.

Extensive documentation covering requirements, use cases, gap analysis, architecture, design decisions, configuration and user guides are available. Head to OPNFV.org to the OPNFV Colorado 2.0 Doctor documentation page for details.

OPNFV: Are there other use cases for Doctor that go beyond telecom? Will it work with other types of networks?

Demo team: Yes, definitely! There are a number of interesting cloud and enterprise applications that can use the framework; for example, those with time constraints, e.g. in the area of multimedia and real-time applications (for faster replacement of a video cache associated with peak user times). The OpenStack-powered fault management framework will be useful for anyone operating within contracted SLAs.

Individually-developed features can also be used beyond fault management scenarios. For example, event alarms can be leveraged for quicker triggering of administrative actions. Without this feature, events (or “faults”) can only be retrieved by periodically polling data from a database. In fact before Doctor, the time required to detect and recover from a fault was a few minutes. With Doctor, the time to recovery is less than one second!

OPNFV: What’s next for the Doctor project? Are there other cool implementations we can expect to see in 2017?

Demo team: We certainly hope so, but it will be hard to top our Barcelona demo! As a project and a part of a larger community,  maintenance and continuous improvements to the functionality of fault monitoring, notification and handling are needed and planned for in OpenStack. And as integrators, the community needs rich monitoring functions that can be supported by the broader OpenStack/OPNFV ecosystem.

Recently, new open source communities have surfaced that aim to develop higher-layer network function management and orchestration systems. OPNFV has been supportive of these activities, and a plan to integrate them in the platform is on the horizon. That said, we may see Doctor joining additional collaborative efforts at some point.

OPNFV: Most importantly: How did Mark get those giant scissors through airport security?

Demo team: Mark made all of us sign a nondisclosure agreement that prevents us from sharing any details! (It was either that or he would sabotage the demo…)

For more information, please visit OPNFV and OpenStack NFV on the web or follow @opnfv on Twitter.

We kicked off our intern program earlier this year and are pleased to welcome our very first OPNFV interns! They work directly with the community and receive hands-on development experience in NFV. Each intern works closely with an active OPNFV developer as their mentor on a project that suits interest and community need.

This blog series aims to showcase these interns and the projects they work on, the mentors who are helping with their professional development, and their experience working in an open source community to accelerate NFV.

About Daniel Tudares

Daniel is an electronics engineer with a major in Telecommunication. From Venezuela, he came to Canada two years ago to pursue a Master of Engineering degree in Electrical and Computer Engineering at Carleton University in Ottawa, which hhe’ll complete by the end of the Fall 2016 term.

During his Masters program, he did a lot of research on Cloud Computing, NFV, Software-Defined Networks and virtualization. He had the opportunity to join the Centre of Excellence in Next Generation Networks (CENGN), an associate member of OPNFV. His internship project consisted of deploying a bare metal lab infrastructure based on the OPNFV Pharos lab project specifications. As the only Pharos community lab available in Canada, it will help other students like Daniel to kcontinue research and give back to the OPNFV community.

In His Own Words

We had a chance to chat with Daniel during LinuxCon earlier this year. Watch the video below to hear from Daniel directly about how he got started, his project to build a Pharos Lab at CENGN, and what it’s like to work in the OPNFV community.

“Hopefully my experience will open me the doors to keep doing research in this field and to be able to keep working with great open source communities like the OPNFV!”

Interested in becoming an OPNFV intern or mentoring an OPNFV intern?  More details about the OPNFV Internship Program, including specific projects and current intern opportunities, are available on the OPNFV Wiki. You may also contact internship@opnfv.org.