 So what is going to be the final product? Will it still be OpenShift and you will just merge the technology technologies or there'll be a new product line? Yeah. So we're going to have, from a Kubernetes perspective, we will have one brand, the brand will be OpenShift. Okay. So let's start with the host level. So we'll start with CoreOS. So what we did is we said what became Container Linux, originally CoreOS Container Linux, what that did incredibly well was all of the automated operations over the year updates. The one thing that it didn't necessarily have was it was built on a kernel, like a Gen2 kernel, which didn't necessarily have the breadth of applications certified against it that REL has had in the past. So what we did was we are taking the work that the previous atomic team had done around miniaturizing the REL kernel for an immutable container bringing over the automated updates and over the year work, and that repackaging will be called Red Hat CoreOS. Oh, interesting. So the atomic brand will sunset over time. Red Hat CoreOS will be our container-centric immutable. So that will replace the project atomic host? Yes. Okay. Yes. And that will be mostly, is it rebranded Container Linux or Container Linux plus what you explained, bringing all those capabilities to that? So really, the way we look at it is there's two really important pieces. We want to have the best of the operations over the year, and then we want to make sure that every ISV that's ever certified against the REL kernel can continue to just work. So we get the best of certifications. Customers don't have to go through any process, but they get brand new operational model if that's what they choose to have. So that's the first step. We're going to, our offerings will be still available on REL if customers want that, but also now on Red Hat CoreOS. Excellent. So that's the host level. Okay. The second thing is at the platform level, the Kubernetes platform level, and what we really found was when we talked to tectonic customers, what tectonic delivered was a really great operation centric, Kubernetes cluster centric viewpoint, right? What it didn't do was anything that was sort of really developer centric, application centric, DevOps centric. So no pipelines, no middleware, no service catalogs and so forth. So what we're going to do is we're going to bring over the tectonic console. So a richer set of operation level viewpoints, we're going to bring that into OpenShift. So the brand that will continue there will be OpenShift. OpenShift's had a much richer enterprise footprint for deployments for Kubernetes. And so what we'll end up having is if you are an application centric person logging into the platform, you will see what you used to see with OpenShift. Very application centric, very robust in terms of building applications. If you log in as an administrator, you're going to see what's going to look and feel like the tectonic console, all the Prometheus work. So our belief is that we're going to now have a richer, we're going to have as rich an experience for the application developer, we're going to have a richer experience for the operator. And then the third immediate piece that we'll do is we're going to take the tectonic platform operator and make it infinitely simpler to manage and update that platform because we're getting Kubernetes updates every quarter. That's interesting because I don't know how I put it, but depending on who you talk to, sometimes OpenShift is seen as a redhead, not for, but distribution of Kubernetes, but quite kind of far from upstream communities, but tectonic was always seen as kind of always upstream. So is that correct? So not 100%. So tectonic was always just upstream. That was the claim was just upstream. And then obviously they integrated Prometheus, they integrate Flannel and SD. So just taking upstream, tectonic or Kubernetes never gives you enough to do everything. You still have to have network storage monitor, right? So that was tectonic. OpenShift was always, it still is, everything from upstream Kubernetes. And then there are some additional things that we have done that we will get back into mainstream Kubernetes, but that we had done ahead of the community. The community just didn't have the ability to accept them. So there's some more advanced routing capabilities we have in there, one or two little things, but from purely a Kubernetes perspective, any customer who wants to grab any Kubernetes tool from the community, Cube CTL, Cube anything, everything works exactly as you would expect in OpenShift and always has. Right, okay, so how challenging is this integration? Because as you said, operators will see tectonics if I'm not wrong and then we will see OpenShift. So how long will it take to integrate it? So we've already got some baseline integration done. So three months we've got that done. We showed a bunch of live demos this week. The next release of OpenShift, which will be 3.10, which aligns to Kubernetes 1.10 will be out sort of the end of June. So that will be the first time customers will see sort of tech preview of these early integrations. So roughly four month window pretty good for two teams. And then we'll see further things in 3.11 and 3.12. So for the second half of the year you're going to start to see a lot of these things come out. The other really big thing that we're doing as part of this is that operator framework that CoreOS had initiated probably 18 months ago, they had delivered a Prometheus operator, an SCD operator and a Vault operator. Last week at KubeCon we open sourced that to the entire Kubernetes community, which was great. We saw a lot of interest in it. We've actually, and then this week we talked about it as something that will be fully integrated, fully supported by the OpenShift platform. And we got 60 or 70 ISVs who signed up and said we're fully behind this. We actually saw five or six database vendors in the last week who have built working functional operators. So our belief is that's going to be the new way that ISVs are going to package their software. They're consistently telling us Kubernetes is going to be sort of the new unit of compute that they're going to build against. And people love this idea that I'm going to use an operator to basically build an on-demand service that will run anywhere, sort of self-driving. It's got life cycle management built in. It's got an SDK to allow you to have all the knowledge about your application. It'll do some basic metering so you know what's going on. So that's for us really, really exciting.