 All right, how do people, this is Kubernetes and GlusterFS finally playing nice together lightning version. I'm Jose, this is Ashik. Let's see what we can do in five minutes. Hi, so GlusterFS, so mostly everyone knows GlusterFS, I think. So GlusterFS is a distributed storage software defined storage file system. So it aggregates storage from different nodes and gives out as a single volume to the customer. Or the user. So how it's minimum level is bricks. And from a device and LV is created and that small part of LV is a break. We take LVs from each node. I mean bricks from each node in terms of GlusterFS and create a volume out of it and mount it anywhere. We have protocols supporting fuse and NFS and Samba. So that's what GlusterFS is in shorter version and Hackety. Hackety is a RESTful interface which can manage GlusterFS volumes or create GlusterFS volumes for you. You don't have to go behind the screen and create the LVs, VGs and manage your disks. So Hackety will take care of it. And Jose is going to continue on the cool part. Cool part I see. All right. So these days GlusterFS and Hackety are fully hyperconverged with Kubernetes. That just means that they're running as containers in a Kubernetes cluster serving storage for other Kubernetes applications. Obviously with hyperconvergence this means that you guys can save money in your data centers by not having to buy separate storage appliances just by a couple SSDs or something. The applications in Kubernetes have native access to storage from Kubernetes which means that it's a little less network latency and it's less prone to outages from the network because if your apps can't access your storage that means your Kubernetes cluster is down and you have other problems. And GlusterFS nodes don't need to run on every node all the time. They only need to run the nodes that actually have storage on them. So you can actually have nodes that are not completely alike and the GlusterFS daemon set will take care of making sure they're running in the right place. And we kept the ability to easily scale out that is brought with GlusterFS. Here's a little picture of how things are supposed to look. You'll see that Hackety is running as a single pod on one of the nodes. It doesn't matter which node it's on. And the three nodes that have storage attached to them have GlusterFS pods running in them that are all logically linked together into one GlusterFS cluster. And as you can see there they don't have to have the same topology of disks on every node. We just need to know what the topology is so that we can serve it to the Kubernetes applications. And we also allow for dynamic provisioning if you're familiar with that in Kubernetes. The administrator on the right there provides a storage class which defines that applications can use some underlying storage. And the admin manages that by saying an endpoint that tells it where to get access to the GlusterFS pods and a REST URL that points to the Hackety REST interface. And after that the user on the left there only needs to know the name of the storage class in this case Gluster. And when you create your persistent volume claim over on the left there it gets attached to the storage class. And then creates a persistent volume in some storage somewhere in this case dynamically creates a Gluster volume on your Gluster storage. And that then gets attached to the PVC and can be used by an application. And that is now a persistent volume that can get attached to a PVC and used by a Kubernetes application from the user. And unfortunately at this point there would be a demo but the demo video itself is about four minutes long which is about as long as its presentation. So thank you very much. He's a chic. I'm Jose. Here's a couple of links. These slides will be online after this presentation. And hopefully the video too. We'll see. Thank you.