 Good evening upscale. So the etcd non-troller, as I'm going to call it, is a distributed control plane for managing etcd. Just to get into a few questions you may have already, yes this is working code, yes this is available, get hub link at the end. Sure it's a bit of a pitch. No, I'm not going to debate the difference between operator and controllers. No, what about ISM is not a question. Yes, I can justify my pet project just as well as you can justify your pet project. But first we should talk about what etcd is. According to the website, etcd is a distributed value key store that provides a reliable way to store data across cluster of machines. It's open source and available on get hub. etcd gracefully handles leader elections during network partitions, tolerate machine failure including the leader, communication happens over raft consensus yada yada yada yada. What they won't tell you is that the membership of etcd is expected to be handled outside of etcd. So how do you do this? There's a couple ways. You can do it manually if you want. That's how a lot of people do it. You can run etcd admin from plan 9. It wraps system D startup of etcd and incantations are abstracted away, simplifying them out. Or you can run the etcd operator, which is cool. It's software that's able to run in conjunction with the Kubernetes API to administer etcd clusters. You say I want one. It gives you one. Kind of nice. And what's even best about etcd is that the Kubernetes control plane runs on etcd. Sorry, the Kubernetes data store runs on etcd. So if you want to run etcd, just run kubernetes so you can run etcd. You've just walked into a recursive problem. You know, you can build one cluster, your chicken cluster or your egg cluster depending on where you start to run your etcd operator so you can run your actual chicken cluster. So how do we get around this? Well, look at the etcd operator. It tells the Kubernetes API server to create the containers and administers them from there. It does this from outside the containers. The key to the non-troller is that we want to move that intelligence from the operator outside of that into something that's coupled directly with your etcd instances. Okay. This becomes your distributed system problem, but this is something that we're kind of used to dealing with around in the world of Kubernetes. So how do we move that? Well, we take a look at what the operator is really doing. It takes care of membership, you know, sorry, it observes membership via service discovery with Kubernetes API. It obtains resources from the Kubernetes API and then it manages those etcd instances. If kube isn't there, we still need to do these, you know, a couple of these items, you know, outside of kube, but we can still use that intelligence to do the rest of it inside. Okay. And I'll be honest, this is probably already done for us. If we take a look at the container world, you know, we're going a lot of ways saying, hey, I need ex containers, right? This can be done from a Docker run command. This can be done from any of the container run times. Even in the Kubernetes world, there's a bootstrapping mechanism under the static manifest. So this is already there. You know, the resources have been inside of you the whole time. Hand in hand with that goes the service discovery aspect. Okay. How do we know where we're running? How do we know what we should connect to the cluster? Well, again, it's been there the whole time. You're probably already running some kind of service discovery mechanism, you know, in existing environments from console. You can leech off other items like AWS tags that are running on instances that will be running your Kubernetes cluster. Or you're probably maintaining inventories, spreadsheets, number one service discovery mechanism. So the meat of the operator is really about that intelligence of how do I run at CD. So the non-troller breaks this up into a conductor which handles which at CD, which at CD should be running and any additional commands which are given directly to CD. And the second one is the driver, which is really taking all those invocations around at CD and rolling them all out. The key is that you get the same outcome between the operator and the non-troller. Even though this is one is not the Kubernetes way, you're still doing a lot of this the Kubernetes way. Okay. So what I've said here is probably blasphemy to several people. You know what? You need to get info from Kubernetes. That's the way. Spoiler, it's not. So don't be afraid to do something the wrong way because in, you know, in this old Irish saying that I just invented myself to fit on one slide, sometimes doing it the wrong way really tells you what the meat of the problem is and you can take it from there. Thank you.