Blog

By Ranny Haiby, Samsung

The ONAP community is excited to announce reaching a significant milestone – the general availability of Guilin, the 7^th ONAP release. Named after the Chinese city of Guilin, which is an important junction of major waterways, this release delivers major functionality for several important Telecommunications use cases.

Our work on the Guilin release was aimed at addressing the needs of modern communications networks, with a focus on 5G wireless networks and open RAN. While adding new features related to these technologies, we have evolved ONAP capabilities in orchestrating the latest generation of network functions that utilize a cloud native architecture. During the release development phase, we made numerous improvements to the code quality, security, and maturity. The team working on integrating the software components and delivering the ONAP software introduced new testing tools and procedures that streamlined the process and will definitely make us even more efficient in future releases.

The new functionality in this release was prioritized based on a set of requirements driven by Communication Service Providers (CSPs). Either through their direct participation in ONAP, or through participation in LF Networking’s End User Advisory Group (EUAG). We feel that the Guilin release is ready to tackle many real-life use cases including, but not limited to:

• 5G Network slicing – We demonstrated the capability of orchestrating network slices in all three domains – RAN, Transport, and Core
• O-RAN Integration – We are proud to be part of industry wide collaboration around open Radio Access Networks. During the Guilin release we aligned the ONAP interfaces to be compatible with O-RAN Alliance specifications and the O-RAN Software Community modules.
• Cloud Native Network Functions – Moving in parallel with the evolving architecture of the network functions ONAP orchestrates, the community significantly improved the way ONAP handles Cloud Network Functions (CNFs). It is now more aligned with the way ONAP handles VNFs and PNFs, leading the way to orchestrating hybrid network services using any combination of technologies.

We are always striving to make ONAP more efficient, secure, standard-aligned and simpler to use. This effort continued during the Guilin release and covered many aspects of the software. We have continued improving alignment with the latest specifications from ETSI-NFV and 3GPP, acknowledging the fact that standards compatibility is a key consideration for deployment in production networks. We introduced several improvements to the policy design and enforcement mechanisms. Based on experience from previous releases, we improved handling of Physical Network Functions (PNFs). We addressed many of the issues raised by our end users like support for IPv4/IPv6 dual stack that is crucial for 5G RAN.

In addition to functional enhancements, non-functional requirements are important to help productizing ONAP represent ~50% of the total scope of Guilin. These include advancements to the gating process, testing sets, and security.

With Guilin being the 7^th release of ONAP, we realize the goal of keeping up with ever evolving needs of CSPs is a long-term task. That is why we invested in keeping up with the latest and greatest versions of our underlying software components, and constantly improving the ONAP platform itself. Some efforts are already in the works but require more than one software release to complete. Stay tuned for new and exciting software modules in the coming releases.

The ONAP community deserves a huge round of applause with this software release. Working tirelessly through a global pandemic, 260+ developers from 30 companies and 5 universities addressed 2,950 epics, user stories, tasks, and defects! We are proud to have this level of diversity and participation almost 4 years into the project.

Finally, any piece of software is useless without proper documentation and training. We welcome you to review the extensive documentation for Guilin made possible by the community here and we welcome new contributors: https://docs.onap.org/en/guilin/ (Note: ReadtheDocs is the official project documentation). You can also take a sneak preview of a new, interactive Document Navigator in Beta here: https://safratech.net/onapdocs/ and let us know your feedback. We are also pleased to announce that the Certified ONAP Professional (COP) exam has launched. Engineers who develop, deploy, and scale networks and services can now get grow and confirm their skills in this comprehensive module.

We are hopeful that our end users will find Guilin as exciting to use as it was for us developing it. Although our work is never done, this release brings the Telecommunications industry a step closer to fulfilling the promise of truly automated networks.

Learn more about Guilin here and learn how to get started with ONAP here.

By Catherine Lefèvre – ONAP TSC Chair

The LF Networking communities from CNTT/OPNFV, and ONAP participated in the first ever LFN joint “virtual” conference as a result of the COVID-19 pandemic. The conference was redesigned from a 2 full-day Face-to-Face event to a 3 half-day virtual sessions. The sessions saw record levels of registrants (528) and attendees (370) with a diverse range of participants from operators, supplier companies, and universities, represented by 39 countries (36% located in EMEA, 35% from NAR/CALA, and 29% from APAC). 

The event contributed to the communities’ forward progress thorough this unprecedented time as 60+ presentations were shared including 4 joint cross-community sessions.

The ONAP agenda was organized into four tracks – Presentation of the next release requirement candidates (Guilin Planning); Reinforcement of our “Security by Design” principles; Continuation of our ETSI/CNF alignment and Others (Demonstrations, Test Automation/DevOps, Doc, Lesson Learned, etc.). The OPNFV/CNTT community had an equally packed three days covering key areas like Reference Model (RM), Reference Architectures (RA), and Reference Implementations (RI); including initiatives like OVP.

I was impressed by the high attendance numbers, the quality of the talks, the community members showing respect for others, the speakers meeting their time schedule, the level of engagement and cooperation during these discussions.

I also felt re-energized by the enthusiasm and the willingness of the ONAP Community to evolve towards a cloud native platform.

A virtual “happy hour” was also held to conclude this event, promoting socialization, a bit of fun, and personal connections. 

I encourage you to check out the 2020 April LFN Virtual Technical Event wiki to view the topics, meeting notes, presentations, and recordings.

To those who attended, thank you for trying our virtual event experience with us and sharing your feedback, we are all learning!

Based on initial comments, we will work with the Linux Foundation to create “more open collaboration time” for the next event along with other improvements. 

Our next “Virtual LFN Developer and Testing Forum” is scheduled  for June 22-25 to carry on the momentum. Save the date, stay tuned, and we hope to “virtually” see you there!

I’m pleased to report that the ONAP Technical Steering Committee signed-off on the 5th ONAP Release, El Alto, last week on October 24th, 2019.

El Alto, meaning “The Heights” in Spanish, is a city in Bolivia that represents the highest major metropolis in the world (4,150 m).

Originally considered to be a catch up release with no new blueprints or features and a compressed timeline, the ONAP community definitely reached “the heights” of open source development by delivering 2500+ epics, user stories, tasks, and defects addressed, marking a significant advance to the platform.

El Alto is driven by three themes:

• Security by Design – seeking to make components with fewer vulnerabilities and more impervious to attack
• Document as You Code – improving documentation, developing new user guides, and integrating Swagger for API documentation
• Don’t Break the Build – increasing test coverage and E2E Test automation

El Alto also delivers several enhancements to existing features like Controller Designer Studio, UI Data Dictionary Screen Improvements for resource creation, HEAT & TOSCA based VNF validation enabled for support of OVP & CVC, VNF Preload Generation, and much more.

Finally, many tooling and process improvements were identified and implemented during this release such as doing Self-Serve project releases (increasing flexibility and responsiveness) and Release Automation Management that will directly benefit the upcoming releases.  And for the first time, we were able to executed a 4 month release cycle instead of the usual 6 months.

I invite you to learn more about the El Alto Release here: https://www.onap.org/software.

What can you expect in the next ONAP Release, called “Frankfurt”?

The ONAP Technical Steering Committee is in the final stages of prioritizing the use cases and the requirements submitted by the ONAP Community. A new blue print, Third Party Operational Manager, will be contributed by Telstra while China Mobile will extend their CCVPN Blueprint, E-Line over OTN. Further enhancements are expected to improve PNF Management, Control Loop Self-Serve capabilities, our journey towards ETSI Alignment, and industry alignment with ORAN, amongst others.

The rise of open source communities increases the cross-collaboration willingness such as 5G/ORAN & 3GPP Harmonization, Acumos DCAE Integration.

On behalf of the ONAP TSC, I offer my sincere thanks to the ONAP Community for making this possible. The team’s tenacity and continued hard efforts have led to another successful release.

Way to go team! Let’s keep the ball rolling into Frankfurt!

Originally posted on the Nokia Blog

It’s always a proud moment when something you’ve nurtured for so long starts to bear fruit.

I’ve blogged before about why Nokia keeps pushing openness and taking a leading role in initiatives like OB-BAA and ONAP, and why we also champion standardization efforts in the BBF and ETSI NFV. It’s increasingly evident that open software architectures will renew the focus on true product differentiation and stimulate collaborative development between telecom vendors and service providers.

This week at the Open Networking Summit North America 2019 we will celebrate another milestone in the path to openness with the first demonstration of how fixed access broadband services (BBS) can be automated with ONAP’s 4th release, the Dublin release.

For those not so familiar with ONAP, it’s the latest shining example of what can be achieved with open networking cooperation. The ONAP community aims to create a global service and network orchestration and automation platform for all domains: 5G, enterprise and fixed access. This is a milestone in applying ONAP to the fixed access domain.

The goal here is to deliver operational excellence and the best customer experience in the design, provisioning and management of multi-gigabit broadband services. We’re demonstrating the extensibility of the ONAP platform in supporting the orchestration of fixed access services across different locations (Central Office and Core) and technology domains (Access and Edge).

Nokia has been particularly active in expanding ONAP’s ability to manage and orchestrate not only virtualized but also physical network functions. This is crucial as we know that operators’ fixed networks will be in a hybrid state, with software-defined elements existing alongside traditional network elements, for many years to come.

We’ve built openness into our software-defined access network (SDAN) solutions from the ground up. The model-based, policy-driven and vendor-agnostic automation found in Nokia Altiplano cloud native access platform can be complemented by ONAP or any other truly open networking solution, giving our customers the freedom to architect and adopt what’s right for their networks. The crux is to become more responsive to future service and network innovations and reduce the lengthy development and integration cycles needed to evolve traditional OSS management software architectures.

Looking ahead, we expect ONAP to play an important role in the industry alignment and feed back into traditional standards developing organizations for automation in fixed access. This is why the BBS use case relies heavily on using open standards such as the BBF CloudCO Architectural Framework and TMF’s Open APIs. 

Join us at Open Networking Summit North America 2019 to see the demonstration on the Linux Foundation Networking booth and hear from Nokia’s Tim Carey and others about how we’re planning to continue this journey with ONAP. The event is an excellent opportunity to witness the latest developments in cloud-native networking and next-gen SDN, so I really hope you can come along.

Share your thoughts on this topic by joining the Twitter discussion with @nokianetworks or @nokia using #SDN #NFV #automation

By Phil Robb, VP of Operations, Networking & Orchestraion, Linux Foundation

The ONAP and OPNFV projects kicked off 2019 with a combined developer event at the Nokia Paris-Saclay facility in France earlier this year.  A few more than 200 developers from those combined communities came together to discuss their next respective releases, plan longer-range strategic priorities, and for the first time ever met together to explore further collaboration between the two groups.

As always, I get energized by taking part in these discussions and planning sessions feeding off of the enthusiasm, and passion for excellence that everyone in these communities exude.  This event had approximately 150 sessions spread across four days as well as an OPNFV Plugfest and 2 demonstrations set up by our Nokia hosts. I want to thank Nokia for hosting this event.  They have always been an incredibly supportive participant in these communities and an outstanding Platinum member of the Linux Foundation Networking (LFN) fund.

A full report is now available, but I wanted to drop a quick blog post though to capture what I personally found interesting throughout the week.  The session slides and recordings are posted to this LFN Wiki Page.

LFN End User Advisory Group

The first thing that I would like to mention is that I (re)kicked off the LFN End User Advisory Group (EUAG) at the beginning of the week, and I’ve had a lot of interest both in email and while at the event on it.  We are planning on our first meeting at the end of the January and if you are an end user interesting in any of the projects within LFN I strongly encourage you to fill out the Membership Application and participate.  The EUAG is a great way to both provide feedback to the technical communities as well as learn from your peers on how best to leverage the current capabilities of the LFN project releases.  I am expecting a very active EUAG this year, in particular with the ONAP and OPNFV workstreams within that group, based on what I heard at the event.

The OPNFV Verified Program (OVP)

Throughout 2018 the work done by the Dovetail-OVP project within OPNFV was expanded to include VNF verification as well as NFV Infrastructure.  A natural benefactor and collaborator for the VNF verification work is the ONAP project, in particular the VNF-requirements project and the VNF SDK project.  These groups have been working together over the past several months and this event gave them the chance to sit together several times throughout the week as well as explain to the broader OPNFV and ONAP communities what they are up to and how others can get involved.  If you want to learn more or are interested in helping to shape the foundational requirements to onboard and run VNFs within an ONAP environment follow one of the links above to get more information.

Leveraging Test Tools and Infrastructure Between OPNFV and ONAP

There were several sessions at the event discussing how ONAP can leverage the years of test tool and system-under-test configuration and deployment that the OPNFV group has developed.  In addition, community members from Orange provided further details on their OpenLab and tooling that they’ve created for systematically layering and testing varying cloud and NFVI components underneath ONAP, then installing and testing the ONAP environment, then finally layering on the VNFs they wish to test in that particular environment.  They also have different “Flavors” of implementation from Core, Small, Medium, and Full allowing test teams to only deploy portions of ONAP needed for the particular VNF/Environment testing. Orange has recently open-sourced these tools and provided them on Github until a home is found for them within an LFN project.

I had an epiphany during these sessions regarding the pairwise integration and system testing needs of ONAP.  Normally, for an open source project that delivers one or a relatively small set of coupled executables, the integration testing is relatively straightforward to stand up the interacting components and test new or modified interactions.  Projects that have the end goal of performing integration testing on distributions, ie large, complex systems with hundreds or even thousands of components all on different release schedules spend nearly all of their effort on building tooling to wrangle the consistent, repeatable deployment, and configuration of such systems so that they can successfully perform tests on them to produce consistent and meaningful results.  The most common distributions in the open source ecosystem are those for the Linux operating system and the thousands of programs/packages that accompany it such as the Debian, Red Hat, or Ubuntu distributions. OPNFV however, builds tooling to deploy, configure, and test open source distributions capable of running NFV workloads. It is actually a superset of a typical Linux distribution.

The epiphany came for me as the recognition of the significant complexity that a full ONAP implementation entails.  While the project creates its own set of executable, it also relies on thousands of other open source components including OpenStack, OpenDaylight, Ceph, and Hadoop (all of which are significant in size on their own).  The result of this complexity is a difficulty in producing, deploying, and configuring an environment that allows for reliable pairwise integration testing which in turn slows down system testing. ONAP will benefit greatly by incorporating and collaborating with the OPNFV testing projects as well as the team from Orange and their latest tools that sit on top.  This dialog started in earnest in Paris and I’m excited to see where it goes from there.

ONAP Interoperability With Other Orchestrators

A session was provided by some of the ONAP community members that initially was meant to explore potential interoperability opportunities with the Open Source Mano (OSM) project.  As the discussion evolved though in instead focused on what ONAP needs to do to support other orchestrators in general. I have heard from operators over the past 18 months that there are a variety of deployment scenarios they would like to explore for ONAP in different parts of their network engaging with legacy components, some of which are existing orchestrators,   The discussion in Paris concluded with those in the room feeling as though adding the capability to convert ETSI NFV-ISG defined SOL-006 YANG models to SOL-001 TOSCA models in the NFV-SDK project would allow for generic interoperability between orchestrators that had chosen those different paths within the ETSI NFV-ISG set of specifications. Furthermore, to properly interact with other orchestrators in an East-West fashion, the group in the room felt that continuing the work to support SOL-005 was an important endeavor.  Participants from this discussion took the action to present these suggestions to the ONAP Technical Steering Committee (TSC) for further consideration by the community. The exploration of deeper interactions between ONAP and other orchestrators is always a possibility as well. If there is community interest in pursuing such work, I encourage those interested to contact the TSC for further discussion.

ONAP Subcommittee Meetings in the days leading up to ONS

The next time members of the ONAP community have an opportunity for a face to face meeting will be just prior to the Open Source Networking Summit (ONS) in San Jose, California.  I am targeting the Monday and Tuesday of that week, April 1st and 2nd but plans are not yet finalized. The meeting will be limited to TSC and TSC subcommittee discussions in order to prepare for the launch of the upcoming El Alto development cycle that will start after the Dublin version of ONAP is released in May.  

During our time in Paris, we had the opportunity to plan for a potential joint meeting between ONAP and ETSI working group focused on Zero-Touch Network & Service Management (ZSM).  There are several community members within ONAP that are also working in the ZSM effort and the time seems to be right for these two groups to meet, share their work and plans thus far, and explore ways to collaborate.  Plans for this are still evolving as well, but the hope is to have a 3 or 4 hour workshop sometime during the week of ONS in order for this introduction to take place.

All in all we had a great week in France, and ONAP and OPNFV are off to an excellent year of collaboration in 2019.  More details about what we learned are available in the full report: https://www.opnfv.org/wp-content/uploads/sites/12/2019/03/OPNFV_ONAP_PlugfestReport_v4_ac_Web.pdf

Hope to see you at ONS in April!

By Timo Perälä, Nokia

The new year will see more than 200 engineers from all over the world gather at our Paris-Saclay site for a Nokia hosted open source event – the jointly held OPNFV Gambia release Plugfest and ONAP Dublin release Developer Forum.

As a founder and active participant in both projects, Nokia is committed to their success and I’m looking forward to an event where the focus is on openness and collaboration. Based on the experience of hosting the ONAP Developer event little more than a year ago at the same site, I’m confident the event will be a success!

For ONAP, the Dublin release Developer Forum is a critical step in defining and agreeing the contents of the Dublin release, to be ready in mid-2019. Nokia has been a major contributor to ONAP, being especially active in expanding ONAP’s ability to manage and orchestrate not only virtualized but also physical network functions. Together with colleagues, we plan to continue this journey for the ONAP Dublin release and beyond.

The OPNFV Plugfest focuses on the Gambia release, allowing developers to fine tune it for different hardware variants, while also providing an opportunity for OPNFV project members to meet and discuss their plans for the Hunter release.

Holding the OPNFV Plugfest concurrently with ONAP helps lay the foundation for future VNF verification and certification activities, a major aspect of ONAP from the very beginning.

In addition to compliance and verification, the OPNFV and ONAP cross-project collaboration topics include automated testing, CI/CD, Lab-as-a-Service and infrastructure, all the way to documentation.

Such cross-project collaboration is a proof of the synergy benefits between the open source projects hosted by Linux Foundation. This was the aim of Nokia and other member companies when creating the Linux Foundation Networking fund, an umbrella organization within Linux Foundation to bring various networking open source projects closer together and coordinate their activities.

In addition to hosting and contributing to the co-located event, Nokia will have demonstrations of our lightning fast 5G networks and cutting-edge open hardware for the network edge.

The event is an excellent opportunity to witness the latest developments in open source networking projects, so I really hope you can come along. In addition to in-person participation, remote access to sessions will also be provided.

Please note that prior registration is required – please register as soon as possible at https://www.linuxfoundation.org/calendar/onap-ddf-opnfv-plugfest/

The agenda for the event, currently being finalized, is here: https://wiki.lfnetworking.org/display/LN/OPNFV-ONAP+January+2019+Session+Proposals

Share your thoughts on this topic by joining the Twitter discussion with @nokia and @nokianetworks using #OPNFV #ONAP #NFV #cloud

See the original post on the Nokia Blog here.

Congratulations to the entire ONAP community and extended ecosystem on the availability of ONAP Casablanca, the project’s third release! We have come such a long way since ONAP’s first code release, Amsterdam. With a thriving community of more than 492 developers hailing from 31 organizations, ONAP’s growing global diversity has come together to deliver an even broader set of features and enhancements that make ONAP even more suitable for global deployment.

Read on for more details on what’s in the release, as well as a brief Q&A with ONAP’s new Technical Steering Committee (TSC) Chair, Catherine Lefevre.

New Features & Functionality
Casablanca introduces new functionality with two use cases important to the evolution of networking: 5G and CCVPN (Cross Domain and Cross Layer VPN).

• The 5G blueprint is a multi-release effort, with Casablanca introducing the first set of capabilities around PNF integration, edge automation, real-time analytics, network slicing, data modeling, homing, scaling, and network optimization.
• CCVPN demonstrates how to provide enterprise services across operators with the use of MEF APIs. CCVPN was first introduced onstage during ONS Europe with the help of China Mobile, Vodafone, and Huawei. (You can read about the ONS demo here)

Casablanca also includes new features, architectural changes, deployability enhancements (see the “7 Dimensions of Deployability”) and bug fixes. Some of my favorite highlights include:

• The design time environment includes two new dashboards to simplify design activities.
• The runtime environment includes new lifecycle management functions in both the Service Orchestrator (SO) and its three controllers, expanded hardware platform awareness (HPA) to improve performance, geo-redundancy, support for ETSI NFV-SOL003 for VNFM compatibility, MultiCloud enhancements, and edge cloud onboarding.
• Additionally, the initial integration with the PNDA project, several new collectors, policy engine updates, and enhancements to the Holmes alarm correlation engine, boost ONAP’s service assurance capabilities.

Community Growth
We’re also very excited to see strong growth among the ONAP community. With an expanded community, we’ve been able to develop more features in less time! For comparison’s sake, the number of contributing CSPs, vendors, and other organizations has increased to 31 up from 24, and Casablanca includes contributions from 490 developers, up from 452 compared to the Beijing release. Equally important, the community has expanded beyond technical concerns to collaborate with other open source projects such as OPNFV, CNCF, and PNDA, as well as standards communities such as ETSI, MEF, and TMForum.

We also plan to integrate more closely with OPNFV on the compliance & verification program, which will extend to VNFs following Casablanca. The program will allow VNF vendors to test their products using a standardized test suite and receive a verification badge.

To get more color on how the community came together for this release, I sat down with ONAP TSC Chair, Catherine Lefevre. Here’s what she had to say:

Q&A with Catherine Lefevre, ONAP TSC Chair

Can you share any anecdotes about the release and community coming together? We heard rumblings of a great conversation in the LFN booth at ONS Europe. Please elaborate.
While some of our ONAP members were engaged in talks and demos at the ONS Europe, I took the opportunity to organize several meetings. The purpose was to collect feedback from the community to better understand what their expectations are related to the new ONAP TSC. The number of participants turned out to be larger than anticipated and was really energizing, highlighting improvements in terms of technical leadership, communication, documentation, consistency across the platform, plus much more. This feedback became part of our TSC roadmap. An “ONAP TSC” project was created in JIRA (https://jira.onap.org/projects/TSC/), allowing us to track our TSC action items to drive change and accountability based on the feedback from the community. We wanted to manage TSC in the same way we manage any new ONAP feature.

If you had to summarize the release in 3-5 sentences, how would you describe it?
The goal of Casablanca was to consolidate our projects foundation while evolving to modularity and aligning to industry standards i.e. MEF 3.0, ETSI NFV-SOL003, etc.

On the deployment side, we made great progress in streamlining the ONAP installation using Kubernetes, adding a broader range of physical/virtual storage options, enhancements to backup/restore, etc.

On the design time side, two additional artifacts were added to continue driving the unified design palette to help product managers, VNF owners, and anyone interested to build on ONAP (DCAE Design Studio – control loop workflow & Workflow designer for orchestration workflow)

On the run time side, we increased the service assurance footprint by adding new High Volume VES (Virtual Event Stream) collectors and performed initial integration with the Linux Foundation PNDA project in DCAE (Data Collection Analytics & Events). PNDA containerization, application onboarding, and deployment are currently targeted for Dublin. We also developed new functionalities to support physical network functions (PNFs) and audit capabilities through A&AI (Active & Available Inventory).

On the Security side, we integrated many of the ONAP components with Application Authorization Framework (AAF) and increased the CII badging compliancy.

Casablanca provides blueprint updates to 5G and CCVPN as well as a sneak peek of compliance and verification updates related to VNF testing. Can you explain how this will benefit the ecosystem? Why are these developments significant?

ONAP 5G & Cross Domain Cross Layer VPN (CCVPN) Use cases are definitely the cornerstones of the Casablanca release.

The ONAP CCVPN Use case exercises many aspects of ONAP by building a high-bandwidth, flat and super-speed Optical Transport Network between two carriers and across multiple domains.

The ONAP 5G blueprint starts to address two of 5G challenges: Network optimization and the extension of Zero Touch Orchestration/Automation to Radio Access Networks.

These use cases, 5G and CCVPN, demonstrate the willingness of carriers to work together on common requirements. The ONAP community is a fantastic Software Defined Network platform for academic research, proof of concepts into complex topics, benefiting from a lot of technical expertise and highlighting the desire of the ONAP community to develop a platform that focus on building a future together.

What makes this release unique, and  what is your favorite thing about Casablanca or the way in which the community came together?
The acceleration of the ONAP community diversity highlighted by the rise of VNF and 3rd party vendors contributing to the ONAP Casablanca release.  They also now have a better understand the source code and are able to develop themselves.

The scope of the Casablanca release was substantially larger in comparison to the Beijing release while our testing capacity did not increase respectively. The last 3 weeks were challenging, but we had a great Integration team with a “never give-up” mindset and a group of Project Technical leads who acted as a single team. This is really my favorite part, having a large team coming together, focused on a shared goal, working collaboratively to achieve the impossible –  the power of the team spirit!

Now that Casablanca is out the door, what are you anticipating for ONAP’s next release?
We plan to have a minor release in early February 2019 to address some security and code enhancements.

The scope of our first 2019 major release, Dublin, is not yet finalized; however, the ONAP TSC has identified several guiding principles they would like to put in place:

• Pursue our Continuous integration / Continuous Deployment Journey to ensure development issues are addressed quickly by leveraging more automation

• Security by Design – re-enforcement of security awareness at each milestone of the release; not only at code freeze.
• Document as You Code – dedicated focus on improving the documentation all along the release cycle.

Stay tuned for more to come in the coming weeks …

Join us to help shape the next ONAP release!

Dublin Release Developer Design Forum: The next design forum will be conducted jointly with the OPNFV Gambia Plugfest in Paris, France from January 8-11, 2019. The event, as the name suggests, will focus on Dublin release planning and explore various synergies with OPNFV. Both members and non-members are welcome to attend. More info here: https://events.linuxfoundation.org/events/onap-ddf-opnfv-plugfest/.