 Awesome. Welcome to this talk on the last 12 months of Bosch, which has been pretty exciting. I do have a question to ask, which is you look at the events page of Clive Vandries, all the summits and the days everywhere. And as you scroll through this very short page, you left with the question, which is, where is my Bosch event? I, you know, poor Wally. He's like, Bosch has been in our six years of what. Castiel can't get its own day. We had it once, but that was even a side thing. I'm pretty sure there are enough people in the world who desperately just want to spend some time understanding Bosch better. In lieu of that, and then we don't even have a track. There's no Bosch track. So I get 25 minutes to tell you everything the Bosch team's been working on and the wider community for the last 12 or so months. And but I can't start yet because I have to tell you about the fire exit. The city of Boston thinks it's more important than I tell you about what to do if a window goes open and the air pressure sucks one of us out. And I'm sure that's how buildings work, but that's in the news right now. And I want you to make sure you grab that person before they go and go out the window. Then you get to go in the news. I don't think that's in the fire exit announcement. Certainly by now you've read it. And if you are currently making a fire, please just wait till I finish talking and then get back. So I've broken up the review of the Bosch team. So I'm not on the Bosch team. That sounds a lot of fun. I just get private messages from Dimitri saying, hey, have you tried this feature out? They're like, no Dimitri. I didn't know it existed. And then I get to be excited by them. Some of them I don't play with straight away to my own detriment. And I should just do what Dimitri tells me to. So, but it does make me very happy to get the opportunity to share what the teams have been working on and I guess the wider community. So the, what is there? Oh, I guess first there was the new logo in the last 12 months, which is changing all our lives radically. And, but you know, all my old swag goes, we don't even have swag. Dimitri, come on, dude. Where's my T-shirts? Where's my conference? Where's my, but we have a logo. All right, one thing we do have just the other day is they shipped a refresh of the site. It looks fantastic. I guess my favorite feature is the inline search. So you don't have to play around with Google queries where you used to type the thing you'd want to query and do site colon Bosch IO and then Google would find it for you. Now there is search. There is also a book I wrote, which is new in the last 12 months. People who've read it have said thanks. Well, perhaps it's useful. The story it tells is a story of you as someone who against your will has been told to learn Bosch. I felt that that was a real thing right now. And it means we don't have to start with let's boot up Bosch, which is like a minefield of like everything hard of our Bosch is just getting it running the start with or your credentials, the networking. At the time, that's the highest at the same time your interest is lowest. So let's start somewhere else. So it starts with, it assumes you've been put in front of an environment and let's look at how it works and then come back out and by the end, you're super excited, guaranteed, absolute promise or your money back. There's a video I put out, which is, I don't think there's a lot of content. So there's that I'm just sharing. I was made to remember, Hammer put out video series on Bosch, which I don't have a link to, but there is a course you can buy. All right, so onto the CLI. Please make sure that your version number is not one. All right, if anything else I talk about is not working, it's because you skipped this slide. Obviously you wanna run that command. I don't think definitely technically works as an answer, but you know, there should. So one of the things, whilst I know many of the, I did ask a lot of my friends and Bosch people, people I know use Bosch, what their favorite things were. And there's a blog post going with this where I attribute each of these to different people. But certainly, a range of people all said that these environment variables are one of their favorite new things. The ability to just source a file that says this is what I'm doing or a shell script or bubble uses this, buck uses this to target environments. So the first four are targeting an environment. The new move towards having good certificates. I for one was a generous cargo culture of certificates across Bosch files that I didn't know what they did or how they worked. And they didn't work because they were just from 2012 or something. So one of the things we have, and we'll get onto variables, but with the new certificates, it's more and more CLIs, including the Bosch CLI, are respecting a root CA and making sure that that works. Instead of using a minus D flag, we've got the Bosch deployment environment variable. And the last one is super useful if your Bosch is like a Bosch light. And I'm talking about Bosch light running on another infrastructure. So you don't have direct access to containers. This allows you to SSH to any of those VMs or containers through the Bosch. And certain tools would just do all this for you. Here's an environment example. Hopefully none of you put your Bosch on the public internet. Let's not do what everyone does with Vault. There's like, you know, you can search through all the lets and crypt registries and then by Vault, it's like, look at them all. Everyone's just putting Vault on the internet. Bosch has lots of ports that listens in and just don't, please put it on a private network which leads to the question of a great Nick so how do I get to it? You might have the EPNs but it's becoming a lot easier to have a jump box. And so you have the Bosch or proxy environment variable which you can run a SSH session locally and then in all environments, all the shell scripts, sorry, all the terminals where you want to talk to Bosch, you just set the Bosch or proxy to that port and all your requests will go through the jump box. I put the Credhub one in there too because to use Bosch, sometimes you need to use Credhub to reset credentials and have them regenerated or to fetch API keys and that's the proxy for the Credhub CLI. So, hopefully you've used the Bosch deployment repo but certainly at this time last year it was one of the most exciting things to come into my life and with it is the Bosch createM for command. So, just to quickly walk through this command, you might have copied and pasted it a few times and not really knowing why it was doing it and why it was doing it. So one of the core ideas right up front is the idea of a base manifest that does as much as possible to work. The Bosch one struggles because it does need a CPI and things but it's got nearly everything in it that you need to deploy a Bosch VM. You do need something that talks about what CPI so we have operator files and I'm gonna talk about operator files shortly. The next line is the state and the vastore. If you're ever wondering what is really my Bosch? What describes my Bosch? Like what is the thing I should protect with all my life? And it's that state.json. That is the little database on your laptop that says what is your Bosch? And the most important part of it and that's not in my slides is the reference to the disk. You can get rid of everything else in that file but as long as you know what your disk ID is you can rebuild your Bosch. And so if you have not yet moved to Bosch deployment and you've been using Bosch init or something else as long as you've got that state.json and you've got that disk reference is the simplest thing in the world to move to upgrading and deploying using new system because all you need is that state file. The vastore we're gonna talk about when we talk about explicit variables and generating credentials. They get stored locally and then minus O these operator files. Little changes and you can see now it is as easy to deploy a Bosch without the UAA as it is to deploy it with the UAA. It's as easy to deploy a Bosch without Kredhub as it is to deploy it with Kredhub. As such, we will always assume that you have, I assume you've got the UAA and Kredhub and all Boschers. I think most of the Bosch releases I work on slowly deprecating a reference to not having Kredhub because it's verbose and it's just so easy to have. I'd say Kredhub is stable and working. Okay, it will fill up its disk and hopefully they fix that problem. Has an audit table that it's very enthusiastic about putting entries into and because of an audit table, you can't delete things from audit table that's irresponsible. So it just grows and grows especially if you put concourse on top of it. So keep an eye out for that but Bosch is a little better behaved. And adding a dump box user, you may have discovered in the last 12 months that you stopped being able to easily SSH into VMs. The solution to that is to generate an explicit user called Jumpbox with a private key that you have locally and now you can SSH or do the gateway. Great, you want a jump box. Probably one of the most unloved parts of everyone's infrastructure is that Bastion VM. They just sort of spun up with Terraform. How old's that VM? I don't know. Is it backed up? Is it got a disk on it? Oh, no one knows what it even is. And so it is as easy. So you might not have ever thought about it but Bosch Create VM can deploy anything. One variation of anything is nothing. Nothing is what we call the jump box. Now, okay, it's not quite nothing. We'll put some users and whatever but I mean plus and minus, what this is doing is pretty much booting up a blank VM. Put a persistent disk on it if you like. Put your jump box user could be on that. But now we have the full ability of Bosch Create VM to update the base stem cell. If there are any other things you wanna apply to it then we can always use Bosch. We have ownership of that VM in a fashion that perhaps you've never really had before with your Terraform-profissioned sort of VM. With those two things in mind, the bubble team or the Bosch Bootstrap team have taken upon themselves to make this even easier. Then they're not just managing the jump box and Bosch but also they provide a Terraform plan for all the different environments they support. So if you've got nothing and if we wanna ring how to get started, the bubble project is a really valuable place to start. And whether or not you wanna keep using the way they do jump box, the way they do Bosch, that's not the point. You've got started and you can start showing success, you can start getting Cloud Foundry, whatever else running. I don't see the way I deploy Bosch as with tool called buck and this time next year, it might be something else but I like this because what's the next thing you should probably deploy after the Bosch, whatever pipeline system you're gonna use to deploy everything else. If it's not on the same VM, that means you have to Bosch deploy it, which means you just deployed it without using a pipeline and it becomes the risk. So the idea of sticking concourse straight on the same VM means that it's up and you can start using it to deploy everything else. I actually started using buck in production not because of Bosch, I wanted concourse. And so I actually was running it just because I needed a new concourse in production and I fell in love with it and so now I use it for everything. Has buck up is a virtual box, light. CPI 8 OS is obviously pick an 8 OS and light just means it will be on that CPI but it will be a warden CPI. Another thing that's new is multi CPI, which kind of two different major use cases. One is using the same CPI like the OpenStack CPI but allowing it to have talking to different OpenStack installations from the one Bosch. It's like a multi region, so a multi AZ sort of support. I believe that was one of the reasons like Swisscom, whoever added this at Swisscom. The other one I heard a few years ago and I have not yet tried this out but I think the mission I've amused over this might say someone will give us some complaint. You see this kind of complaint about, this takes too long, errands take too long, compilation takes too long. It's like wouldn't it be cool if we just had the warden CPI on every Bosch and then compilation jobs could just run inside that, errands could run inside that. I still think it's cool. So hopefully Demichie makes that easy. One of us should just at least try it first. And the sort of the next main thing that's of running environments that's valuable is DNS. Way back in the day we had DNS. So the way it worked is a bit like what's up on the top. Some suffix dot Bosch, it's all internal to your environment so it's your own root. And then it's sort of reading from right to left is the deployment name, the network name, the job name or the instance group name and the index. And that allowed you to sort of reference things across your cluster without having static IPs. And I don't even like that. The downside of the original implementation was it was written with power DNS which was running on your Bosch. So if you're upgrading your Bosch or if your Bosch was down, nothing could talk to anything which is not the best implementation of DNS. So it was both a solution and a terrible anti-pattern. And fortunately the team went about a different solution and at its core is basically caching the DNS entries locally on every machine so it's all done and there's no central point of failure. It supports aliasing so you'll start to see, so you get that same default every instance group gets its own known entry but that kind of ugly. And so your environment can specify DNS entries that mean something to you. The best example, well the one that's in the top of my head is the CFCR project is used heavily to have nice DNS entries that are internal. And I trust at some point this will be default and it'll just be involved and installed on everything. But it does mean you need to start thinking about addresses as not being IP addresses. Over time there'll be more and more DNS entries rather than IP addresses and then eventually you won't see IP addresses, you'll just be playing with DNS entries. The next topic is deployment manifests. The original demo was given this time last year to bring to my mind what the big change had happened in the thinking about things was deploying Cloud Foundry. Even this time last year, big effort had gone into this idea of what is CF deployment which is now the only way to deploy Cloud Foundry. CF release is gone, CF deployment is it. But this is the canonical story that just should make you fall in love and that is it's one base manifest and one variable. It's incredible. Like there's no more mashing together of spiff files or spruce files or guessing like what makes this work is not just the new Bosch CLI, it's also Cloud Config and Runtime Config. But there's this idea of systems you want to deploy having a base manifest that works. You don't have to mash three things together to get things working. There should be something that just works for everyone and then operator files that tweak it to make changes. This one by default is gonna have a Blobstore VM. You might not want that, you might want to use S3 or there's an operator file for changing it to S3 and getting rid of the Blobstore VM. So a base manifest that works with operator files to bring it to the environment that you want. So what are variables look like inside your manifest? They're these double parentheses, tokens and you'll get an error if you've missed one so it doesn't just fail later. I love fast failure. I don't love failure 20 minutes from now. So if you're missing a variable, the error might be obscure, something might complain that it's not in config server or something like that, because we'll explain config server and credit up in a second. But there are a number of ways to provide variables and the minus V flag is one of them. So that's implicit variables. This is explicit variables. That's what the documentation calls them to meet you. It's not quite how I think of them but this is the secret variables and that's the other one, the external variables. So to me, that's an external variable. It's something I have to provide. It's provided by me probably because it's something to do with the external world that only I know about. But let's see if deployment has a lot of in it is internal variables that I don't care about. It was really bad because I cared so little that I just copied them from deployment deployment. The JWT token, no idea what it's for. I'm pretty sure I was using the same one from 2013. Don't know what it does. That's why I don't get to stand in production environments because I'm immature. Fortunately, fortunately, this is what this is all about. It's much easier to do the right thing. You have to work hard to bust this and to start providing bad credentials. So there are literally 80 of these things in the currency of deployment. Like 37 passwords, 41 certificates and SSH and an RSA. And it just works. You don't have to figure, as long as you, if you do change any DNS entries, you've got to regenerate some of them and that's about the only thing you need to know. You might need to know how to use Credhub to get them back out if you need to use them externally. So you'll find this section, obviously it's very long, it's got 80 of them, but you'll see if deployment manifest or any Bosch deployment manifest, hopefully it's got this section. So different types. And the list of types is somewhat dependent upon the back end config server. At the moment, there's kind of two, maybe, like there's Credhub and then there's not using anything and just letting the CLI do it for you. But I would like to assume you're using Credhub from now on until someone else makes one that's other different and we can talk about it. So the Credhub documentation lists all the different certificates, but if you're just deploying stuff, you don't even need to care, it does it for you. If you ever want to rotate secrets, one option is to just delete them and deploy again and it will make them again. And pass them all to the places that you need to, who cares? You don't care what the certificates are. Passwords, keep rotating them, except encryption keys. Don't, don't change that one. Nothing good happens if you change the, like today's the encryption key, what, like, because it's the last day you were employed here, what is special about that? Don't touch the encryption key. Okay, so I mentioned that there are different ways to set variables. The Bosch CLI, there's three main commands that sort of have this idea. So obviously we've got createM from deploy. So Bosch createM creates that standalone VM, whether it's a jumpbox or a Bosch or whatever. Bosch deploy is where we actually talk to a Bosch and ask it to do the work for us. Though one at the top, Bosch Int, you've hopefully seen by now, it's where you can do the interpolation of the manifest, just to see the outcome. It also has a path expression, so you can then interpolate and then pull things out. It's like a little mini-JQ built into it. And if you don't know what JQ is, then you missed all of 2014. I think Alex Srirachi said, you know, JQ was like his tool of the year for 2014. And no, I didn't just ask him, and he placed it in history, that I asked him in 2015, and I'm the one that remembered what year it was. He's not a fucking freak. Oh, he is a freak, but not in that way. He's a good freak. Not a crazy date remembering freak. Sorry, Alex, if you're watching this. He was also the author of Spiff, so I think it's always worth bringing that up, that anyone that uses Spiff, it's his fault. So, different ways. Most of these are about reading variables, different ways. The bottom one is a read-write, and this is where if you provide this vast door, all those generate those internal credentials, what the documentation refers to as explicit variables, that'll be generated into that file if they're not provided some other way. So, when you do Bosch create end, you'll often see vastdoor equals creds.yaml. That's where they all are, sitting on your file system, which apparently is not a great thing, but that's where they go. Now, I know that there's either a pull request or an issue discussing the idea of them being somewhere else, but that's kind of the story at the moment. But for Bosch deploy, we have this other idea, and that is the CredHub story. Now, I'm gonna tell you quickly why we have these two phrases, config server and CredHub, because at the start of last year, config server was the abstract idea of what might be implemented by something like CredHub. CredHub was initially not a public open source project idea, it was gonna be a private project, proprietary project, and so they needed abstraction in the end, they made it open source, and now we have to talk about the two things, but they are somewhat synonymous. You can implement different config servers, I think it's a pretty simple API, so if you want to back by vault, back to why something else, you can implement that. But the main one you'll ever hear, anyone talk about is CredHub, so we somewhat talk about them, as one. And so you don't specify the variables, they'll just get generated and fetched from that. You can pass them still through, you can pass minus V, but the generated ones can be generated in CredHub, and you can manually put them in a CredHub and they'll be pulled back out. So you go off and get your Amazon secrets there. From Bosch's perspective, no, they're external, but they're secrets, so you can put them in a CredHub and now no one else needs to know about them. Very exciting part, and it was not exciting when I first saw it. I was quite mad about it, but then I matured and grew up and got used to it and it's better. Because, so the operator files are a way of modifying YAML, so remember we told the story of that one base operating, but one base manifest, Bosch deploy CF, Bosch deploy CFCR, Bosch deploy MySQL, a base manifest that works. But you do need to probably make some changes, like you might want to change its name because there's already one with that name. Change the sizing, change the secrets or whatever. So the Bosch CLI implements this notion of operator files, implemented by a library called GoPatch, and it's this idea of explicitly making changes. So instead of just mashing two YAML files together like we sort of did with Spiff and Spruce, we make strategic changes. So replace and remove a path somewhere down a nested tree and then insert, replace, whatever. You can search by tag labels and that URL has a full explanation of everything. I had not seen the before and after column thing, so that was interesting to see. And what I like about it is, and why I like it better than what I used to have, is that it fails fast. You start to build out your own set of changes to upstream. You're deploying Cloud Foundry, you're deploying CFCR, you're deploying whatever, or Bosch, and you assume you know what's coming so you make your changes. Well, you want to know if they make changes to the assumptions. You want it to fail so you go and check it. You don't want to just mash it together and deploy something. And so that's what I liked about it was the fast failure. For those of us writing releases which hopefully everyone does, it's not just for deploying my SQL. Bespoke code is a perfectly valid place to, you know, Boschify something. You know, given CEI and everything, I mean, you can merge through and build out a nice pipeline, building bespoke Bosch releases and deploying them through a pipeline. So it's a much smaller footprint of things to go wrong than putting things on top of Cloud Foundry. Given that you can create final releases, given that you create compiled final releases, you can then put them in dark data centers and, you know, you've got a whole pushing things to the edge story that you don't really have with a big Cloud Foundry. Given that you all should be writing Bosch release, at least how to do it, here's a couple of new things in the last 12 months. And there's no additional slides, I'm just going to talk about each one. Okay, there's no specific slides for each one. So Bosch Process Manager, or BPM, is an attempt to solve a couple problems. One is the copying and pasting across all Bosch releases of shell scripts to manage processes. So if you've never written a Bosch release, the way we start and stop processes is with Monit, which is nice in that it's not something that Cloud Foundry team wrote. Sometimes we might accuse them of non-invented heat syndrome. Well, they picked Monit. Good on them. Now, we don't know why they picked Monit, but they did. And so every Bosch release needs to have a starting point, which is a Monit file. It can be blank if you never knew that. It can be blank. But it can specify one or more processes to run. And Monit will take over the responsibility of restarting it if it dies, or booting it up initially. So typically what we then do is we have this wrapper script, and scripts, we'll call that to other scripts, to manage processes, kill things, reap it, set up environments, environment variables, create folders, et cetera, because Monit starts with a very clean. And there's also no isolation between all our jobs. Now in the world of containers, we start to get used to things to be a little more constrained in what access they have, especially when we start mashing together Bosch releases from different vendors. So Bosch Process Manager makes it super nice and clean to like a small YAML file to say, run this process with these arguments and these environment variables, please. It's so much nicer than all this shell script. It was funny when they first talked about it six months ago, they pointed out all the shell script, I realized I hadn't seen it for four and a half years. Like it was there, but you just sort of look straight past it. It's like, you know, your children's clothes on the floor. It's like, yeah, probably, if you're a child, your clothes, you just walk past them constantly. It's like, didn't know what it was that was, been there a week. Well, I didn't know that. I know it's at the front of my bedroom door. I didn't know it though. I know it, but it's like, it's a bit. So when the moment he pointed that out, it's like, I can't believe that we've just been living this way. So BPM has been great. And over-fact of most things, I think CIF deployment has an op file to turn that on. Some other projects are just moving straight to BPM. Bosch vendor package. To make it sense in my head, I started just calling them language packs. So it's like, if you bring bespoke code, anyone like Ruby project, you bring a Ruby project, you need Ruby. We're not gonna do interactive. I'll just answer the questions for you. I've thought about them in advance, so I'm the best qualified dancer them. But it is five points to me. It's my system, I score, and I give myself five points, which means I'm winning, because none of you got any points. So we don't have like a build pack system, which might be nice, but what we do have historically is just copying stuff from other releases. You're like, oh, you've got Ruby? Not the right version, better little do. In you come, and you just sort of bring it in. So vendor package is this idea of saying, well, let's be a little more formal about it. If you like the version of Ruby that's in that release, how about you just take the final release package that's done and just reuse that? So you don't have the blob, you don't have the packaging script, you just have the artifact that's done. Now, it will be compiled, you'll still have to compile it, but you now can just keep refreshing. So whenever they get a new version, you can just run the command again and get the new version. So I guess the next thing was instead of just saying, well, Ruby is all these places was to have a nice catalog of them. So there's a GitHub organization called Bosch packages, Bosch package, single plural. And so Dimitri's been curating a sort of minimal, some releases that are just like focused. So there's one for Ruby, one for Go. The Java one is perhaps my favorite because Java's quite a tedious thing to find and to get as a standalone thing without, like I had a lot more children, but every time I downloaded Java, I had to give one of my children to Oracle. And the paperwork alone made that tedious. All right, obviously the loss of my children was bad too. All right, that was, but we hadn't named them yet, so we didn't meet as much. So it all worked out. Jesus. So, it's like, how far, right, just keep going, eventually we'll find that. The nucleus of the nonsense. When you're deploying Bosch releases, you know, you do Bosch create release, Bosch upload release, Bosch deploy, over and over and over again. Fortunately, some people got really annoyed by that and made it simpler. So in your manifest, there is, you can just say the version's called create instead of latest. Latest means it has to be uploaded already. Create means the Bosch Selie will do those three steps for you. It will create it from wherever you referenced it. It actually referenced things that are not that released. You can say over somewhere else in my fault, my machine is a release, I need you to create that one as well. And then it will create it and upload it and deploy that very specific version. That's right. If I've also got, my consumers, they're always had to use rebase because I had CI pointing at the same machine I was deploying to locally. It still maintains the very specific version. Right, okay. Cool. I had not seen an issue but then I'd only been playing it for a week. Dimitri had told me about this but I had my little command that I ran and I was a fucking idiot and he fixed it and now he's right and I'm wrong. That is kind of the topic, the theme of the talk is here are all the things I was wrong and he was right about. But Bosch Gen, I'm right about that and he is wrong. I think it does, it takes dirty, there's no force, yeah. It assumes it's a dirty project and what he's saying is when you run Bosch create release it gets angry at you if there's any commit changes that haven't been committed and so you then have to type minus, minus force. So we've all been doing that for five years and that's a little tedious. And so that all goes away. So no more minus, minus force, no more rebase, just Bosch deploy. So Bosch Gen is something I've been looking up for six years now and that doesn't make it right. That's not a reason, just because something's been old. I have a seven year old child, that doesn't make him right about anything. All right, just because he's got good with the language skills better than daddy and he can talk his way around me. It doesn't make, like you walk away going how would I agree to that? Come back, daddy's thought more about it. No, you can't get in the pool right now. It's time to go to school. It's a tool I've just evolved over time for what makes it fun and fast for me to build Bosch releases. Often makes it easier to write documentation for how to get started at things. Has some fun little things for extracting and the base repo. So if you're making a new Bosch release, it creates a manifest that works. So it assumes the job is there, it assumes in that first Bosch release, even though it does nothing, you can build it and deploy it and iterate from there. And the last thing, I beg upon you. So if you're a release author, I beg upon you to ship final releases that are compiled. I don't understand anymore why you would make me want to watch your stuff compile. Is something good gonna happen? Like there's an ASCII art that's gonna stream down the square. Like what, what is? So you've already compiled it once. You can be the last person. That's okay. So please have a look at that. And you just put it in your pipeline. So it's just compiles it and ships it and there's another blob. And I do make sure you have some other ideas about how to make it more native. And we'll see where that comes to and whether we get to talk about it this time next year. Finally, there's a couple of ideas around backup and restore to make sure you're at least thinking about it. You don't have a production system if you don't know how to restore it after a disaster. You have a career-defining event. That's what you have and you shouldn't. Like there shouldn't be a disaster. It should just be okay, that was annoying and I have an apology email to think. When you think about backup and restore, think about it if you're all thinking about it from what is the apology letter I could write now? Like am I writing an internal apology letter to my team saying I did a little muck up and it's all fixed. No one's affected, we're all good. Do I write it to our users apologizing? Or is it the letter that you have to give to the chairman of your public company that he's gonna send out to the New York Stock Exchange? I know our share price was this. I believe it's now this number because we don't have any data on our customers anymore. So think about the pain that you're... So backup and restore, a couple of options is the BBR project which tries to make a nice holistic approach to backup and restore. Locking things, letting Bosch releases. Not a lot of Bosch releases I think have actually implemented. I don't think any of mine have implemented it. And if you don't mind my use of I don't think, I'll talk to myself about it later but I just don't think I've done it. But more and more Bosch releases are supporting BBR and they probably in mine should as well. And that means that you can sort of just take a whole sort of snapshot and get a backup. And then there's a stock on way project called Shield which gives you sort of a gooey and a whole more granular expression of backing things up. Not just Bosch things but also service instances. So there's a couple ideas there. And if there's one thing to take away it's to ask your local congressperson to demand that we get more Bosch conferences. I know there's some other hot political topics in America right now like why you keep killing your own citizens but other than that, probably number two other than universal healthcare. Okay so number three would be can we please have more time for us to spend together. So thank you very much.