 Hello, everyone. Welcome. This talk, I'm going to introduce you guys a system called a campus. It is a deployment system with general purpose, and it helped us to streamline the OpenStack deployment. My name is Shuo Yang. I'm a principal architect for Cloud Computing in Huawei USR&D Center. Before joining Huawei, I worked for Google for four years in their infrastructure team. So let's get on to campus. When we started this project, we have a pretty ambitious goal. We wanted to build a general purpose deployment system so that the system can help us as a hardware vendor to deploy any complex distributed system onto the hardware. So during each of our design decision, we have extensibility as our primary design goal. Although it's not limited to OpenStack to deploy OpenStack, it really helped us streamline OpenStack deployment like a charm. It will be open sourced under Apache 2.0. And I want to mention several highlights for this project. First, it has a very small code base, 100% Python. I think it's around 5,000 lines of code. And it has successfully helped us to deploy several dog food cluster. And please check out our project in our Wiki page at this link. So let's take one step back when we go into the detail of the campus. I'd like to share with you guys the concept called the data center as a computer. It's a concept coined by industry veterans like Google guys, IBM guys. And what is a data center as a computer? If we look at the computer in the 90s, we have this CPU as the processing power. We have this as the storage capability. We have NICS as the networking and connectivity capability. And we have this open sourced operating system called Linux. But Linux in the early 90s wasn't a very pleasant system from the user perspective because it needed a lot of domain knowledge to get it running for a regular job. However, nowadays, if you have a live CD, I can install this Linux in my box in a link. So let's fast forward to the nowadays data center. Nowadays, data center, we have this compute servers. That's processing power. We have a storage server that's like a disk, a traditional disk. We have switch. They are networking capability. And fortunately, as of today, we have a very vibrant open source cloud level operating system called the OpenStack. Then what is lacking? I think we need an automated deployment process. We hope we have a general purpose. We have extended. We have an open system. So because that's a very important piece of software, I think a lot of wonders are working really hard on this problem. Qobar is a pioneer project. And I think people are talking about this project in this conference widely. And the field, that's another tool offered by Myrntas. And I think if you guys are developers here, DevStack must have a choice. But in this talk, I'm trying to give you an appetizer talk. I really want you to join my other talk tomorrow. It's more technical. Hopefully, after that talk, I can share with you guys my thoughts and my vision that why we want to build a compass system. So let's take a look at life of deployment. And as I said, we want to have this deployment as a general purpose system. As a hardware vendor, you provide a switch. You provide servers. They are connected to each other. And before the software deployment process, it's normally called a rack and a stack. And having that, you will normally have some kind of a host operating system installed or some kind of a hypervisor. Because you are building a distributed system, that's a distributed pull-up for processes. These processes are configured correctly so that they can talk to each other. And they form a distributed system. And at each layer, you can see there is no lack of a two-chain. In the networking gear, you have SNMP. You have other particles. And you have IPMI to control the server. You have Cobbler or Razor to control the OS provisioning. And also, you have Chef, Puppet, this configuration management tool to configure this processes and the configuration. For Compass, we are building another layer of software. We want to do away with those boilerplate code. We want to enable the user, the operator, or in Google's term, SRE, to be able to really think of the problem itself. What kind of distributed system? You really want to deploy. That's the value of this project. And Compass, as I said, from day one, we decided to be extensible. We decided to make it programmable. Therefore, the key components include a RESTful API server. In this demo, I will show you a Huawei front-end UI. But you can see, as a third-party solution vendor, you can write your own front-end. And also, we have this modularized functionality module. We have a hardware discovery module. We have a configuration management module. We call this in this slide as a package deployment. We also have an OS provisioning module. And for us, we designed this system in a plug-in architecture. We have our Huawei hardware plug-in written when we design the system. But when we test our extensibility, we add 200 lines of code to fully support HP hardware. You get a sense of how extensible the system is. So again, like configuration management, we have a Chef plug-in working on OpenStack scenario. I can see the possibility of working with other configuration management software vendors, like Ansible, like Puppet, like Thought, all this stuff you can imagine. So as I said, this is extensible. Currently, we work on OpenStack. We have a streamlined system for Ubuntu and CentOS. But you can see, with this RESTful API, we can easily extend those systems to Chef, another very popular system in this community. We can support other hosted OS or hypervisors. And more importantly, we can support other hardware, like OpenComputer project. I welcome you guys if you have any interest, we can talk. So this is a demo session. So I will give you a real demo of our production installation. This is a video shot in our research data center. Let's play it. So as I said, before doing any software deployment, you need to have a rack-and-stack process. This is Huawei's research data center. This is a topology of our current video shot. And after we have our hardware well connected to each other, and by the way, in tomorrow's talk, I want to share with my thoughts about how to automate that process. In this one, as I said, we have RESTful API. We wrote a front-end UI to consume that API. This is like a wizard-based. If you as a deployer, as an operator, you follow this question page by page, you will be able to get an OpenStack system out. This page is showing you that by managing the networking gear, you can automatically discover the compute resource in a topology-aware way. Think of the real deployment in your data center. You normally deploy several rack-offer servers. They normally automatically match to this switch. So in this demo, we just select a subset of those. But in normal case, you select all. So this page allows the operator to configure all the necessary credentials in the OpenStack cluster. So after you are done with that, I think the next step is the most error-prone step. We all know that as an operator, if you really want to config your OpenStack networking configuration as error-prone, we have this wizard-based step-by-step system. After answering the question, you are able to get the system out. Not only we can allow the user to use the config the way to define the system, for like tenant network or storage network, you can use the default value because those are not visible to the end user. So this one is a public network. You need to configure that because you need to answer which IP block you want to offer to the user. As I said, I think in this demo, we are using the default value. So this page allows the user, the operator, to automatically fill in the server name. Think of a real deployment. If you have hundreds of machines, config the host name is pretty tedious work. And we allow the user to specify a set of pattern to name the servers. And if you are done with everything, you can proceed the real deployment. So this is the page to track the real-time progress of our system deployment. As I said, Compass provided you a network topology-aware way to look at your hardware. You can see this is a topology view of our installation. Other than the topology view, we have this list view. Just blink. I think the last note is the controller node. It takes a little longer to finish. So as I said, this is the graph view in our front end. And this is the list view. OK, I think we are done with the deployment process. Let's play with our just deployed cluster a little bit. After you log in, you go to your project page. You configure your tenant network. This is the capability offered by Neutron. We created one network for some fun. We created another one. And after that, you create a virtual machine and connect those to the tenant network. So this step, I think it is showing the network topology in this tenant. So after that, I think we log into the VM, log into that to see what is happening. I think that this is pretty much the demo and what we have done in our research data center. I welcome all your questions. And I really want you to join me tomorrow in the afternoon for a more technical in-depth session to discuss all these benefits. And I look forward to potential collaborations. Thank you for your time. Thanks.