 Hi everyone, my name is Garrett Mueller. I'm a technical director at NetApp, and I'm going to be talking today about our storage orchestrator for OpenShift. Trident is an open source, fully supported integration with OpenShift that we've had for a couple of years now. I'm going to get kind of deep into how it works, and so you have a better understanding of how that's done, and I'm going to talk a little bit about what we've learned just running an application in OpenShift, which we've had to do, and that's how Trident works. So what is Trident? Trident is an open, like I said, open source integration with OpenShift. It also integrates with Kubernetes itself, integrates with other orchestrators as well, and it's kind of our one-stop shop for any kind of container orchestration. What it's intent is to be able to enable on-demand self-service volume and storage and data management. So today, if you're familiar with the Kubernetes paradigm, you create PVCs, and we'll talk a bit about that in a second, and it will go ahead and manage the entire process for you after that. So it's all about automation, and it's about getting out of the way of the engineers, the developers, the users that want to be able to take advantage of these platforms, because they don't care about the infrastructure underneath and they shouldn't. We should be able to provide these capabilities, the capabilities they need, at the speed that they need them. And the second important bit is there, how do we provide those capabilities in such a way that we can also protect the infrastructure from those users so that they don't overrun what's available, they don't impact the other users of the system at the same time. And so a big part of what we're doing is we're enabling administrators to model classes of storage and restrict things in certain ways that align with what they actually have on hand and what they want to allow their users to be able to do. And the whole thing is automated end-to-end, it's a production-ready, fully supported integration, so you can actually call our 1-800 number and get support for Trident, even though it's an open-source integration. Some interesting facts. It's shipped in 2016, so it's been around for quite a while, especially in this space. Based on technology that we built in 2014, we started off with some Docker integrations very early on. It still supports Docker, but more and more our customers are moving in that direction in the direction of OpenShift, and so we have to make sure that we have it supporting that as well. It was actually the first controller-based external provisioner for Kubernetes. It's not a standard plugin, and I'll talk more about what that means in a second, but it really is a very intelligent integration that watches what the API server is doing and can respond in kind end-to-end. So it has a really full, comprehensive understanding of what the cluster is doing and what people want from it. A lot more than you would get out of a standard plugin. And it supports all of our storage platforms, and in fact, you can support them all at the same time. So I'm actually going to go pretty deep here into how it works. So this is Trident and how it's deployed. It actually deploys as a deployment in OpenShift. It runs as a pod inside the environment. It has its own backing SCD store to keep track of the metadata that it needs to keep track of, which is understanding of which volumes is provisioned, how they're going to be managed, and so on and so forth. You can see we have front ends there, which are the Kubernetes plugin. We have a Docker plugin. We have a prototype CSI plugin, which is the container storage interface, if you're familiar with that. So a big part of what my team does at NetApp is we work in open source. So we work in open source communities. We work upstream in Kubernetes. We work upstream with the CSI community as well, helping evolve these paradigms. And on the south side, you can see we have all of our different storage platforms. We also now support cloud volumes. You may not be aware of this, but if you're familiar with NetApp, we're known for the data center. You've got all these big iron boxes that can do that. And we still do that really well. But we also have virtualized versions of all of our storage. And we also have cloud volumes now as well. So we are the first party NFS service in Azure. So if you actually go to Azure and get NFS storage, you're getting it from NetApp. We're running the service for them. It's not like a marketplace add-on or something like that. It's the native service from Microsoft. We also just announced this morning we're doing the same thing with Google. So you can go ask Google Cloud about that. We're providing NFS service for Google as well. So Trident can actually orchestrate the provisioning and management of all of the different kinds of storage and do it all at the same time. So you can imagine that over time, we start to understand a lot about what the storage is, where it is, what you're trying to do with it in all of these different environments. So we start adding capabilities. Like we're the first ones that were able to unlock the ability to use native cloning in OpenShift. So what you can do is actually in your PVC, when you're creating a volume request, you can say I want a PVC from an existing PVC. Under the covers for the platforms that support it, we can do an instant clone of that data set, no matter how big it is. So it's very powerful, especially in like CI CD scenarios. So one level deeper, just as I was talking, so Trident is a controller. It's got an OpenShift cluster in a deployment. It gets its HA that way, just like your other applications would. And what it does is actually listening to the API server, waiting for PVCs to show up that it needs to provision. And what we do is we say, okay, here's a PVC that is against a storage class that we understand. And we'll go ahead and create a PV and the backing storage and then hand that off to OpenShift. OpenShift will then take it from there. And then mount the storage when necessary with the individual pods that require that storage. And then we can go ahead and manage the entire life cycle of that storage on the other side. So it's very powerful but also completely invisible to the end user. All they see is I asked for a PVC and I got a volume right away, just like they would expect if they were running in a cloud platform. So the way that storage classes work is you can have a gold, a silver, and a bronze class, for example. You can name them whatever you want. And the way this works is you'll actually configure Trident as a Kubernetes or OpenShift administrator inside of OpenShift itself and then tell us what these pools mean. So gold might mean it's on SSD. It might mean that it has an IOPS level of, let's say, 15,000 IOPS or 20,000 IOPS or something like that. There are going to be properties that are metadata inside those storage classes that the users don't see. All they see is the name. And then we actually figure out which pools of storage on the other side. It could be cloud storage. It could be on-premises storage. It could be anything that matched those requirements and then we'll provision one of those for the user on demand. But Trident handles all the automation of that on the back end. Between the storage class and the Trident configuration, that's where you configure the policies that tell Trident how to automate that process within the boundaries that the business requires. So this is how volume creation works. So a user here on the left-hand side, Trident's running in the middle. I've got an ONTAP and a Solifier system, which are two different storage platforms that NetApp provides on the back end. And the administrator actually configures storage back ends in Trident. We add those back ends to it. There's a REST interface to Trident. You basically just post those configurations to Trident and it will suck those in and auto-discover the capabilities of those boxes. Then you define storage classes in OpenShift that consume those back ends. Again, very generically. So I think in storage classes, a generic way to model storage and the back ends are the specific requirements for individual back ends. Individual storage platforms. Then we actually detect that the user created a PVC automatically because we're listening to the API server. Then we actually find the storage pools that match the class that they ask for. So in the PVC, they're going to say, I want a gold class. They have no idea that it's Trident actually providing this. And you can have multiple versioners, in fact, running at the same time. And we'll go ahead and go, okay, it's a gold class. That means this kind of storage. Then we'll create a volume. And in this case, we picked the Solifier array over there. And they asked for 10 gigabytes. So we gave them a 10 gigabyte PV. Rewrite once. It happens to be iSCSI. But again, the user has no idea that it's iSCSI underneath. All they know is that it looks like local storage inside the container that's in the pod that's running. Right? And it's a gold class of service. So it has, there's a certain expectation of performance there. There might be an expectation of backup and recovery times, like RPO, like the recovery point objective, and things like that. So that's a high-level understanding of how it works under the covers. It goes pretty deep. If you want to go deeper than that, you can come talk to me over at our booth over there. But I want to talk about one thing we learned while we were going through this process, which is simplicity in this kind of environment, it turns out, is really hard. So we started with this interesting problem. We tried it. Because try it. We tried it. We tried it. We tried this interesting problem with Trydent, because Trydent itself has that SCD store underneath that you saw. And we actually needed a provision of volume to store our own metadata. And we were like, okay, well, we're going to have to document how you create, basically do all the automation that Trydent does the first time you install Trydent so that we can, from then on, do it all automatic. That seemed really stupid because, you know, why would we want to document the whole process in the first place? So we came up with this, what looks now a fairly complicated process of we created an install script in Bash that creates multiple pods and hands off everything. So it launches this launcher pod that then launches this ephemeral pod. This ephemeral pod is actually Trident without the SCD requirement. And it creates a PV that we then run the real Trydent pod on top of and land the running Trydent instance on top of that PV that we created. Now, the problem with this is, I mean, it's cool when it works. The problem is all OpenShift environments are different. A lot of people are standing up for the first time and don't know what a broken cluster looks like, let alone some of the interactions that are required here. And so what you end up with is you end up with a bunch of logs for each one of those pods as well. And so the debugging process when that goes wrong is really onerous. So you end up, we try to create easy ways for you to get all these logs and be able to parse this, but there just was really no good way to make it really easy to diagnose what went wrong. Usually it's just one setting somewhere or something wasn't quite working right in the cluster in the first place. So what we did is we recently reinvented this whole thing and we rewritten it a couple times actually, this is our third attempt and the installer now is written in go and it actually starts Trident itself and runs the whole process end to end all by itself. So it doesn't try to run it all in the cluster and then do all this complicated handoff, it just runs it itself, it brings up Trident in this ephemeral mode, it provisions a volume for it, all the logs are then centralized and it kind of reads out the way you would expect through one interaction with the console and when something goes wrong it happens right away and you notice right away and you can kind of see it right in front of you. So we just released that about a month ago and it's been a lot better, a lot easier to diagnose but these are the kinds of problems that we're dealing with on a regular basis just keeping things simple because in these desired state environments you get a lot of these different processes that are running in different places and just being able to understand where one thing ends and another thing begins and where failures might be occurring in an application that you don't know can be a real challenge. So we need to do everything we can to try to make this easier. What we like to do also is helm charts of this. We can do helm and templates and what not with this but the provisioning of our own storage inside of that environment is still a challenge especially this kind of complicated workflow that we need at the very beginning. So we're still working with the community to try to make it easier for us to be able to do that because we would like a one-click install version of it. It's right now pretty easy. It takes about five minutes when you have everything that you need to configure it but we would like to make it even easier than that. So that's pretty much all I had for this overview presentation. This is our website, netapp.io This is where you can go to find out all about our open source technologies our integrations with things like OpenStack Ansible OpenShift We actually have a Slack channel so if you want to communicate with us directly we're all out there and you can chat with us. We'd love to talk to you some more and that's all I have. Thank you for your time. If you have any questions I'll be up here.