 Hi, and welcome to this video presentation for Red Hat Container Native Storage. Container Native Storage brings you the ability to provide a hyperconverged storage solution for OpenShift. This means that you can use the same hardware you're using to run your OpenShift cluster to provide storage for your OpenShift applications. You can do this simply by using existing storage devices attached to your OpenShift hardware, or by providing additional storage like SSD devices to those OpenShift nodes. To get started, you will need a running OpenShift cluster ready to go. So in my case, I have a four-node cluster with one master and three worker nodes. You will also need an administrative account with access to the cluster admin role in the cluster. As you can see, my test admin account is listed under users. You will also need to make sure that you add the service accounts for the project that you're working on to the privileged SCC. In my case, I have the reveter and default service accounts listed in the SCC. And finally, you will want to have a firewall properly configured on each of your nodes for GlusterFS communications. In this case, I need ports 4789, 24007, 24008, and a range of 49152 to 49251 open. You can look up the specifics of what these ports do and why they're necessary in the GlusterFS documentation. Now to get started, first you will need to install the deployment tool for CNS. And that's it. Now to run the deployment tool, you will need something called a topology file. This file describes the topology of the storage that CNS will manage. In this case, you need to specify the clusters, which are the GlusterFS clusters that you will manage. For this demonstration, it will be only one, and the nodes within that cluster. You need to provide the hostname and the IP address for each node. Don't be fooled here. I'm just using the IP address as the open shift hostname for this node. You will need to specify a zone that this node belongs to. This can be any number you like, and it helps define the logic for where CNS will provide replication so that it can do it across zones, if possible. You will also need to specify the storage devices that CNS will take control of and manage for GlusterFS. Take note that any devices that you list must be bare devices with no file system on top of them. CNS takes care of creating the file system on the storage device and using it appropriately for GlusterFS. So with this topology file in hand, we can just run CNS deploy topology.json. And we need to specify dash G to tell the deployment script that it will also need to configure GlusterFS on all the nodes. Here it will go over the requirements that this node needs. This client node that I'm using needs to deploy CNS onto the open shift cluster. As since you are logged in to an open shift cluster already, it will use that information to deploy the CNS pods. So we continue here. We want to deploy for open shift. And off it goes. Now, this process can take about 5 to 10 minutes, depending on the network latency in particular for downloading container images to your nodes. However, with the magic of internet video, we just wait a little bit here and we're done. So you can see up here that our deployment has discovered and formatted the storage devices attached to our open shift nodes. And you can see here that we have a number of pods now running. We have three GlusterFS pods, one corresponding to each open shift node that is now providing GlusterFS storage. And a Hiketti pod. Hiketti is the rest volume, rest base or restful volume management interface for GlusterFS. We have a route up here that provides access to Hiketti. This allows your open shift applications to talk to Hiketti this way. And we have a Hiketti service and a set of storage endpoints for Hiketti. Thank you for watching this video presentation for Red Hat Container Native Storage.