 Okay, okay. So welcome everybody. So this session is about what we have done for the interop challenge sub team. So Helen Yeo is actually the engineer that performed all the testing, but due to visa issue, unfortunately she cannot be here, but she will give a similar talk in the upcoming OPMV summit in Beijing in June, I think around middle of June. So if you are interested in the specific details, please, you know, book your airplane ticket and come to Beijing, come to OPMV summit. And I also put Daniel together since Daniel reviewed our patch and helped a lot. Okay, but it'll be just me, even this talk, okay? Okay, so first of all, I will give an introduction or definition on the NIV workload because what we found is that people are confused about the NIV workload. And Jesus. So first of all, what is NIV? So for those of you who have the telco background, this is, you know, goes without saying, but as my experience with the general OpenSec developers, the telco stuff just really confusing them. So all these three-letter or four-letter acronyms, you know? So I pull up just a definition from Wikipedia. So NIV is just network functionalization. Think of it, just try to virtualize those functions that used to be only provided by the vendor device. So for NIV, you'll be able to run these virtualized network functions such as virtualized load balancers, firewalls, what have you on a POTS hardware, hopefully. And this is architecture standardized in SC, so I won't go into details, but like you'll see there's infrastructure, which is basically on the right-hand side is OpenSec and on the left-hand side is all the virtualization techniques you could get, KVM, SAP and all that stuff, and hardware, servers, storage, network. And above is the orchestration layer, so I will go to that. So what is the NV workload? For the internal challenge, we have tested several workloads, right? So in Barcelona, there's LAMPstack and Docker Swarm. And for Boston, there's Kubernetes plus CoCoachDB, which you have already seen in the keynote, and NV. But like for people who are not familiar with telco technologies, it'll be a little bit confusing like what actually we run for NV workload. So in a basic and very limited sense, actually for every workload, we refer to the orchestration part, as you could see on the right-hand side, these two blocks, plus the VNFs, the virtual network functions, like I mentioned, virtual firewalls and low balancers and all this stuff. And what is interop, right? Actually, there has been a lot of interop activities, not only in OpenSight, but also in OpenMV, which is a open source integration platform for the NV implementation. So within the OpenMV community, we have this set of great testing projects that provide performance testing or functional testing in all these areas. But the Dovetail project, which I highlighted, is the most related to the interop efforts because with Dovetail, we're trying to define a set of tests that might help people to identify the interoperability of the OPMV platform. And we have an ongoing efforts called CVP certification and verification program. And also with these efforts, we are trying to establish a certain criteria for the interoperability in OPMV. Now back to OpenStack, we have an interop working group. I think many of you are familiar with this working group. So the famous deaf quarter guidelines are drafted and discussed by the interop working group. So this slide actually borrowed from a talk, also provided by OPMV team during the OMS summit this year. So we have the interop working group working on the deaf quarter guidelines. And so starting this year, I think, we are start to discuss the possibility of have a vertical use case or vertical scenarios for deaf quarter. So AMV is, I think, one of the top on the list that we might try to have a specific scenario for deaf quarter. And here we go with the interop challenge. So interop challenge is sort of like a subgroup within the interop working group. So this effort started back in Barcelona, test the Lampstack and Dr. Swarm. So as you can see from the picture of the repo, it's a little bit blur, but most of all we will write answerable scripts that help deploy these workloads on different OpenStack platforms. So what is the AMV workload again, right? So these three parts, we try to find a suitable like open source project for that so that we could test a open source. AMV workload, so for VNF, we use Clearwater Virtual IMS. IMS stands for IP Multimedia Subsystem. It was a very hard word, I think, about 10 or 12 years ago. IMS is basically a network function that will give you the multimedia experience. For example, VoIP or video conferencing, video chatting. So this is an open source version of Virtual IMS. And for the orchestration, we select OpenL. OpenL was an open source project within the Linux Foundation last year. And this year it merged with OpenEcon from AT&T to form the own app community. So OpenL will serve as the NFVO, which basically think of it as an orchestrator type of thing. And the last piece in the puzzle is VNFM. So for OpenL, JuJu is the default VNFM at the moment. So if you are not familiar with JuJu, please go to the Ubuntu booth and make a confession. Okay, now we have completed the map here. So we have OpenL for the orchestrator, JuJu for the VNF manager. We think of it like a heat superset of heat. And then we have Clearwater Virtual IMS, which we think of VNFM as just instance, right? So now this is our stuff that we are gonna deploy on OpenSec platform. So I think from this you could see it has bear a familiarity with the Kubernetes workload we are running, right? So Kubernetes itself will resemble OpenL plus JuJu and Virtual IMS is actually the cockroach DB that you saw in the keynote. So there are some requirements. That's where the, you know, the building or the characteristic of NFV kicks in. So we have a certain requirement on the hardware to at least be able to run these instances. And the test pipeline is like this. So you, first of all, you configure the OpenSec, increase the quota and create a dedicated security group for workload and add security rules to allow ICMP, TCP and all those stuff. And then you deploy OpenL. So OpenL itself consists of more than 20 containers. And then deploy JuJu, JuJu client and I think there's another component. And then OpenL plus JuJu will deploy the Virtual IMS on the OpenSec platform for you. And then we test whether the Virtual IMS actually works. So as you see from the whole test pipeline, we have borrowed the deployment scripts from the OpenMV Opera project, which basically provide this integration of OpenL and hopefully later on on app. And then we borrow the test scripts from OpenMV Functest. But currently those two are separated. So one of the job Helen done for the interop challenge on an OpenMV workload is actually to write a Ansible script that could automate all the things together without you have to, you know, when this part first, when this part later. And yeah, so actually with regard to interop is actually the step four. We'll test the interoperability of whether your OpenSec platform could spawn up a instance that actually run these network functions. And step five is actually testing the, if your instance that functioning properly. Okay. Here's some of our test reports. So there are some screenshots. I will show a demo that we recorded. So this you could see the logs that when you like install OpenL pull those images and so forth. So overall we test on two OpenSec vanilla build Metakar and Newton and using two version of OpenMV installers. So compass is like fuel, right? So the test result is pass. So the result shows that with these specific sample VNF workload that we could deploy on different version of OpenSec without any significant interop problems. And I think this is pretty important especially for the telco operators because many of them have like different version of OpenSec deployed and the capability for the workload to be able to talk to different version of platforms without problem is pretty important for them. Okay. So our test group was merged rather late, I think, early last week. So I myself I pushed Huawei's FusionSphere team to run the testing. So the feedback is that the test passed on FusionSphere 6.1 but I don't have like details now. I will push the team to run a revsec hopefully to see a more community-ruled results. And we also need like more vendors to help test if the workload, okay, or if not what are the problems, what are the gaps, okay? So some lesson learned here. It's important to use a snapshot. So the installation and configuration of Juju and OpenO is very time consuming. And some lessons about REN Docker and the host mapping. And then, yeah, I think that's it. So, Daniel, yeah, no, no, no, it's okay. So here are some references and here I will show the, actually show the demo video. So I uploaded on YouTube. So hopefully you could see the, yeah, this is what happened when you run the Ansible scripts that we write for the testing, okay? So I think it varies upon how you like actually deploy, but for Helen, we created like nine virtual machines. So seven virtual machines will run the topology of the virtual MS and two will run the Juju component. And there's another one that running all these OpenO containers. So that virtual machine, you could deploy it on the same platform of all the other workloads, and you could also deploy it on a separate instance, okay? So I think I could fast forward a little bit to show. Always, yeah, I'm as clear water. I'm using the SIP client, JITSI. Here is the number of my friend Jane. Let me make him a call. So the call is through the virtual MS instance, we just deployed. Dream. Hi, Jane, this is Helen. Okay, some call to you. I'm good. Why didn't you call me for such a long time? My written phone bill is so high, man. Yeah, so this is our demo. You could search it on YouTube. So some future thoughts. So for internal challenge, we actually required a participant to run, to customize Raphsec and run a Raphsec book, basically 10 pass test to show the results. So this will be one of our future work. The other one is to try more workload types. So for this, for our workload, we select OpenO plus Juju plus virtual, clear water, virtual MS. You could try all the other kinds of combinations. And we try to get more OPMV test cases utilized by the OpenSec internal workload. I think one of the things that we've done pretty good is to bring all the test cases that OPMV community already done and we like composite or reform it to be able to use by OpenSec. So thank you very much and without further ado for our lunchtime. Questions or no? Okay, thank you.