 All right, so hello everyone, thank you so much for joining us today. I hope everyone is enjoying the summit so far and that you enjoy the past two days and that you're going to still enjoy the upcoming day. Today we're going to be taking a deep dive into the open stack architecture of a 5G ecosystem in Canada. And just to make sure that everyone's on the same page and no one feels like they've had, since they're seeing some deja vu's, we did cover this section in the keynotes yesterday. But we wanted to take a little bit of a deeper dive and shed a little bit more light on some of the technical aspects that we covered yesterday that we didn't have the time to talk about. Thank you. Before we get started, I just wanted to introduce some people. So I'll start with myself. My name is Hen Nasser and I'm the Business Development Director at VEXOS. I've been working around open stack for the past five and a half years, a lot more around the business development and the sales side of things. I also wanted to introduce my good friend and colleague, Guilherme. I'm only going to introduce him by his job title just because he's going to be covering, just giving a little intro of himself after. So he's one of our senior open stack engineers at VEXOS. And I also would like to introduce George, who's here with us. He's not going to be presenting, but he did do the keynotes yesterday, which I think gives him an out of this one. He's nice enough to be here with us to answer any questions. If anyone has any questions about Sienna or Encore, he'll be able to provide a little bit more information to all of us. Which brings me to my next point. What is Encore? So Encore is a partnership between the governments of Quebec, Ontario and Canada, along with five technology giants. The reason for this partnership was to build a platform for, sorry, small medium enterprises as well as academics to build new ideas, develop these ideas and take these ideas to the market. This entire, this platform is a 5G platform that provides these resources for free to these different organizations of different backgrounds and different industries. Now, where does open stack fit into all of this? As I was saying earlier, Encore's purpose was to provide these resources to these different organizations. And as part of the 5G ecosystem that they've created, part of it is an edge platform. That specific edge platform has been supported by Sienna. And Sienna took the decision to go with open stack to deliver that platform for a few different reasons. Some of them were mentioned again during the keynotes yesterday and some of which we're going to be mentioning a lot now. So a lot of the GPU's capabilities as well as a few other things that we're going to be mentioning. So this is where Vex host stepped in for anyone who's not familiar with who we are. We are an infrastructure as a service provider. We have public clouds in North America and in Europe. But a lot of what we do is we build private clouds for companies all over the world. And sometimes we do it at home, which is Canada. And this was one of the use cases where we've built one. About two and a half years we built that cloud and we've continued maintaining it and supporting it. And there was a lot of changes that happened throughout these years. So there's a lot of upgrades and a lot of cool technologies that were embedded that maybe we didn't have on day one. And this is where I'm going to pass the mic over to Guillermy to talk a little bit about all the cool things that he's been doing. Hello, everyone. So it's a pleasure to be here. It's my second time in Berlin. So I went to the summit in 2018. This was a great time. So I'm really happy to be here and to be talking to you guys about the architecture that we have for anchor environment. So let me just introduce myself again. My name is Guillermy Steinbiller. I'm from Brazil. I'm the senior open-stack engineer at Wexholtz. I've been working with open-stack since 2013, 2014, more or less. The first release that I worked, it was Icehouse. So I've been working in Wexholtz for four years now. So a lot of accomplishment. So Anchor's environment is one of them. So I'm going to be presenting an overview of the technical aspects of the cloud here. So basically, we have five data centers in Montreal in Canada. So we have a data center in Montreal, Ottawa, Waterloo, Quebec City, and Toronto. So Montreal is Mayhub. So we have three controllers in there, which we run all the open-stack services and also the monitoring, alerting, and among other applications. And we also run a small self-clustering there just to serve as an image pool for the user, for the users for images and snapshots. And also, we have in Montreal two compute nodes, as well as the other data centers. Each data center with two compute nodes and GPUs serving also with GPUs. So those data centers are connected through a 100 gigabytes fiber optics network. So yeah, that's more or less the overview of how they are physically displayed. If we go to the tooling that we have been using, so first of all, we run Wallaby in this cloud. So we have plans to, in a near future, upgrade to the new release of OpenStack. But I would like to introduce more the atmosphere, which is one of the main tools that we have been using. I'm not sure if you guys have heard about it. We launched it officially at the beginning of the summit. And yesterday, Mohammed was giving you an overview in the keynotes about it. But let me just give you another overview of the atmosphere for you guys. So atmosphere is basically a set of ansible roles and playbooks. It lets you manage and deploy clouds really easy and faster. So the cool thing is that you can use the roles independently. So you can, for example, for the architecture that we do nowadays, we deploy Kubernetes. The Kubernetes is the component responsible to run the applications inside the environment. And also we deploy the SAF cluster. SAF cluster, we have created three roles for SAF. We have a role to deploy the monitors, the manager, and the OSD. So if you want just to use the SAF roles, it's totally fine. You can just download the repository and test it out. So basically, yeah, for the design that we have been using so far is deploy Kubernetes, then deploy SAF, and deploy the OpenStack services using OpenStack Helm. It's not only OpenStack. We also have other applications like CertManager for Certificates, NGINX ingress for the endpoints. We have a full Prometheus stack for metrics and alerting. And for the anchor case, we have been developing OpenStack Helm chart for Monasca. It is being used in production by us. We have a patch set that we have submitted, which you need some reviews if you guys can, by the way, help us review if someone uses Monasca. I'm going to be providing some links at the end of the presentation. So you can check it out and maybe try it out as well. So yeah, that's basically the tooling that we have been using for the GPU part. Thank you. For the GPU part, so we offer GPU PCI pass-through as well as VGPUs. So for the environment, we started providing GPU pass-through. So that means one single customer has a single GPU pass-through attached. Throughout the time, we have implemented the VGPU capability. So right now we have a Tesla V100 on each compute node. So we basically are using two NVIDIA VGPU profiles, which is mostly for graphical and computational. So it's more efficient. So you can slice the GPU into four pieces with the profiles that we use, which makes us to make the most of the capabilities of the VGPU offering. But yeah, if you can. So a couple of caveats, most of them for GPUs are already resolved in the community. For example, right now in yoga, you can suspend instances that have VGPUs. So back into Suri, we have the capability of resizing and code migrating instances. But one thing that maybe someone that wants to use VGPUs is that we have an open topic about it. There is a couple of discussions in the community. There is also a bug report that we provided in the links, which is, for example, imagine if you have a compute node crashing, rebooting. So we don't have the MDEVs persistent on the system. So when the node is rebooted, so the MDEVs are just gone. There is no way inside of a database, for example, for you to map a domain into a MDEV device. So what happens is, along with the discussions that we have in the community, one of the most common workarounds that we have is we just iterate over the domains that we have in the host. And we grab the MDEV from the libvert.xml file. And we just tell CSFS to just recreate the MDEV devices into the PCI address and the NVIDIA profile that we are using. So if someone have experience with VGPUs or something and want to iterate over the bug reports to provide you experience or ideas on how to get on this issue, it would be really appreciated. So yeah, that's one of the only things that you should just keep in mind regarding the usage of VGPUs. But yeah, and lastly, when it comes to monitoring, as I mentioned, with Atmosphere, we have been developing, for example, the OpenStack Helm chart for Monasca. And what we do basically is we are using in production and then we have a detection plugin that detects which types of GPUs runs on the system. And then we have checkscripts that just uses NVIDIA SMI command line to get metrics. And then we plot into graphs to be easier for administrator to monitor the GPU memory usage and the VGPU usage for the SMEs. So yeah, that's basically what we have been doing on the technical side of things. As I mentioned, so there's a couple of links here. The first link is for the report of the bug that I mentioned. Among with documentation for how to implement VGPUs and PCI pass through. We also have documentation for the VEX host deployment strategy, a quick guide for Atmosphere. I'm not sure if I mentioned, but if you go to Atmosphere, we have a quick guide. So if you have an OpenStack Cloud which you have access, you just source your credentials. You install talks, and you run talks which is going to run molecule, which is going to create a heat stack. It consists of three VMs for a control plane, three VMs for Ceph OSDs, and one VM for a compute node. So depending on the hardware that you run, it can take around 30 to 40 minutes to get a full cloud like the design that we have been using. That's also what we use on the CI nowadays. So if you try it out or have any other questions, just come to our booth. We would be happy to give you more details about Atmosphere as well as the VGPU usage. So I hope I was clear until now. If I wasn't clear, I think that's time for Q&A. Thank you, everybody. Thank you. The GPUs is an environment for 5G and among other applications. I'm not too in-depth about the real usage. I'm just operate and use the VGPUs. George, do you have any comments? Any other questions? I don't think so. So if you have any other questions before the presentation, just come to our booth. And we will be happy to give you more details. And we're also going to be hanging out over here if anyone has any questions. Thank you very much. You did amazing.