 Hello, I'm Danny Berger, and I've been a Bosch user operator release author for a couple years and more recently a Bosch developer on the Bosch team. Throughout that time I've had some experience working with manifests and know the joys of them and tools like ERB templates for manifests or Spiff or Spruce, but more recently I've ended up using JQ to generate my manifest, which is an interesting choice, so I thought I'd talk about that. Manifests are everywhere, cloud configs, runtime configs, deployment configs, concourse pipelines, and they often vary slightly depending on your environments, whether you're in testing or trying to load test or make sure your new changes are correct, and so they get a bit tedious, and we all have seen these sorts of manifests that you probably have in your own repos and on your own teams to make it easier for them to all start, and so I was trying to use JQ to simplify this. Most of these variables actually come from some more authoritative place, like you've got infrastructure, you've got some networking settings, and you've got some actual user settings, which may end up changing, and JQ can help make those variables. If you have an alternative JQ, you probably, it's like said an AUK, but for JSON data, if you do use it, it's probably for this sort of thing where you try to turn JSON data into more reasonable, readable output, whether that's plain text or JSON in a different format. The other thing it can do is if you replace like that map command with just regular JSON, it'll dump JSON back to you, and combine that with the fact that JSON is a valid subset of YAML that concourse and Bosch can both understand, becomes a more interesting option for manifests. So, some examples might help. One thing you probably use is cloud formation or terraform to kind of help you provision your resources on your infrastructure, and the nice thing about those tools is that you can export all those resources in kind of a labeled list. And once you do that, you can start integrating them into your manifests. So here's an example. JQ has this argfile option where you can import this into a variable name. So, assuming you've got an infrastructure stack named infra, you can reference the region as the value for one of your properties. Same thing with the security groups that your stacks may create. So, infrastructure created a security group instead of copying and pasting the SG1234 sort of thing into your manifest. This lets you reference it automatically. And so, another example, credentials are of course a poor example, as we're learning. And so, it's just a flat file that's JSON where you can set your settings and then reference them as a regular object. Security certificates are another example until we get config server type stuff. I've been using this approach, whether it's from a file system or vault. You can just cat out the result of a command and then import it. Just as a regular text file or in this case, concatenate the two and not have to worry about copying and indenting all your values into your manifest. So, overall big picture in general you have your inputs, whether it's coming from a stack or from vault or actual configuration that you need to change, like scaling how many instances you want. Those go into a file and then you have your render script which takes your actual manifest of JSON-like data and turns it into a manifest that you can send to Bosch or concourse. And once you have all that automated or once you have all that, you can automate that. And the cool thing about that is then you're able to easily and quickly duplicate your environments, whether it's for different development teams or for testing the change on how it affects performance between your releases, all you have to do is kind of create that new setup from scratch. And it's all documented so you just push it out. And since you've heard concourse is great, it makes for great pipelines. So in this example, the top on the left is two core stocks. One is for infrastructure, one is for Bosch. Both of them create the security groups and everything you need. And then the next stage actually boots up Bosch. And it relies on the stack that created it and exports those resources so it doesn't even have to reload like from copying and pasting those values. Continues on to upload cloud config and then goes ahead and deploys a cloud foundry deployment. All without having to copy and paste your security groups or VPC subnet identifiers. Another example of what you can do with it, if you are relying on simple JSON data, you're able to write very simple scripts which can automatically bump the JSON value and they don't have to understand how a Bosch manifest looks to figure out where the instance numbers are. So I made a sample repo, which is something you could kind of push up to your own concourse and let it boot up a whole Bosch director and CF deployment using this techniques. And you could kind of take a look at what the render script looks like to generate stuff from JQ. That's on DPB587, I'm on GitHub, Twitter, Cloud Foundry Slack. Thanks.