 I'm Toby and I'm a engineer at the government digital service and I work on government UK platform as a service and this talk is how the UK government deploy a platform as a service using concourse and open source continuous thing doer. Who here has heard of concourse who here has used concourse who here uses concourse in production. What a few people that's nice and so this has like some technical details in the talk and but it's also a talk about the team and how we use it and how we think that it makes our software development process better and how it makes our users experience of our service better. So this talk is split into four parts. I'm going to give you an overview of like the platform as a service that we run. I'm going to then give you an overview of concourse tool then we're going to go through a simple concourse pipeline how to write one how to make it better and then we're going to go through like the government UK pass concourse pipeline that we used to deploy our platform as a service and then we're going to talk about some of the patterns in that pipeline and how they might be applicable to your software development process. So what is going to keep us. We first have to answer these questions. What is platform as a service. What are some challenges with digital services in government and how we make things better. So who uses a pass or knows what passes. A few people who's use the government service online in like the last week or last month. Who's had to fill out like a paper form. For government service before probably all of us. Let's try and make some of that more online. So we should take these services and we should make them online. Well, a pass is a step towards that. It's not specifically for government, but it's more just about you know developers should be able to build things. They should be able to build and run the apps without having specialist expertise or having to maintain like cloud infrastructure to run all of that stuff because like getting a DevOps engineer is quite expensive and like isn't a very efficient use of like government's money if their abstractions exist. So we have this high queue at work or in the cloud founder community. Here's my source code. Run it for me in the cloud. I do not care how that's the experience that we want our users to have like they just give us some code. It just works. It's broken. It's because the code is broken, not because the platform is broken. And we want our users like to be able to deploy to production safer and faster. We don't want them to go through a lot of waste in their development process because they don't have access to a environment that's like production. We want them to, you know, be able to do live prototyping, share their code with other coworkers or that good stuff. And we want them to also be able to explain. Explore like, oh, we've got this service that runs in like production with five different microservices, but we think that we should pull this service into its own like two separate microservices. And if you've got like a gate kept infrastructure that's different to how you develop, then like you then turn to like architecture and design when kind of what you want is exploration. So here are some examples of platforms of service. We've got some open source ones and we've got some proprietary ones. So gov.uk powers uses cloud foundry, but there are many different ways of building platforms of service. And this is our website. We are UK based web hosting for government services. There are many other government passes. There's one in the US cloud.gov. There's one in Australia and I'm sure there's a bunch all across Europe. I had a brief look at Sweden's and it looks pretty, pretty legit. You can check us out on www.cloud.service.gov.uk. All the links are in the talk page on FOSDAM. So now let's answer this question, right? Like why do government need a pass? Like what are the unique challenges that we have that maybe like a typical private sector organization might not have? Like why is this even a question? Like this is our value proposition. Government should be doing things that matter to you citizens and they shouldn't be like, you know, moving stuff around on paper and like playing with bills. We want to create the concept of a service team, do digital transformation and say like, oh, you want to renew your passport. You don't know, you shouldn't have to know that you have to go to the passport office with a bunch of forms. You should just be able to open up your phone, take a photo of yourself on your phone, get any passport. That is like a dream that you can live right now. Also, like the way that government services are funded is slightly different. Like you sometimes get a project rather than a product, which means you build some software. Then it works now. People aren't going to look at it anymore. And being able to make teams, be able to maintain software for lower cost because everything is consistent because you've got a slightly opinionated platform is really valuable. Also, like it's the government. Like we've got constraints on our team, how our users use our platform. So like our users are in different government departments with different priorities and we're like, please, could you update your software? That's hard. We've also got a lot of workloads running on the pads. We've got people doing all sorts of interesting things from like data feed aggregation to hosting a web app that you can use to report a pothole. Trying to make assumptions about what people are running are quite difficult. And like we have a small team of about nine engineers and a couple of other folks on the team, but we've got to run like a thousand apps. So we've got to like trust each other, but also develop practices within our software development process that allow us to act with autonomy and not have meetings and just collaborate asynchronously. And we're only able to like build and run this platform because we have the open source community of like cloud foundry and concourse and like that's super, super, super valuable. So yes, open source is good. You probably will believe that you're here. So this is the service that we deliver to our users. There's an API. There's a CLI. You can run CF push on your laptop. Your application will get hosted. You'll be able to visit it. You'll be able to serve traffic. Your users will be able to use it. We provide service brokers so you can say I want a database and that will be managed by software as a service. You don't have to worry about managing backing up your database. That's all done. Then we also have to deal with billing and say this is how much this department owes this department because they have spent this much on cloud infrastructure and like, you know, which developers are working on which programs and which services and things like that. And then providing the ability for our users who are building services to be able to see like, oh, how's my app running in production? And these are the tools that we use to do it. We've got concourse in the middle. We've got Bosch, Terraform, Kofana, Prometheus. And I'm going to briefly talk about what they're all useful so then when we come to go through the pipeline we can see how they're used and how they're really valuable. So who here has used Terraform before? It's like pretty ubiquitous. Infrastructure is code. You declare some resources somewhere like I want this network. I want this VPC, these subnets. It will apply them. You make some changes. It worked out the differences. It's really versatile. Who here has used Bosch? Fewer people. Bosch is kind of one of those tools that came before Kubernetes. It feels a little bit data now, but it's really how we deliver all of this software. Like, it's a VM lifecycle manager and also a release engineering tool chain, which is like a huge mouthful, but it's how we package and deploy all of our software. And it has like an applied process like Terraform and works in like an identity way so that you can say, I want 100 VMs and they should have this offer on them. And then when one of those VMs goes away, Bosch is like, that should exist. I want that back now. It comes back. I didn't put it on the slide because it's a bit mean, but Bosch has a very, very steep learning curve and people have produced a wide variety of comics detailing how steep Bosch's learning curve is. And it's got a very, very specific use case, but it is absolutely fantastic at what it does. And we use Prometheus and we use Gafana for visualizing and dashboarding and like collecting metrics about various components in the system. And this might not seem relevant, maybe, but it will be a bit more relevant later on in the talk. And they're really, really useful tools, so if you haven't used them, I encourage you to check them out. So now we get to the bit, which is actually about concourse. The thing about concourse is you try and compare it to other things. It's been used as a CITD tool and it's really good at it, but it's just a thing which does things. That's what it is. And sometimes it will do them continuously. This is a quote from one of the people who work on the concourse team. Check it out, concourseci.org. And it's a continuous thing, do it. It does things. But really it's about automation and extensibility and we're trying to work out the process that you and I want to follow when we're building and engineering software. And we want to make that streamlined and we want to automate that. And sometimes you and I will use the same stuff and we can share the same resources and code and all that. And sometimes our process is a bit weird and so I shouldn't have to come along to your software and be like, please support my use case. I should be able to use the bits that are common and not use the bits that aren't. And that's one of the design goals that make it really versatile for our use case. And there are four concepts that we kind of have to go through so we can understand how our concourse pipeline is going to work. And some of them will make sense and some of them won't make sense because you're used to thinking about them as the word and not how they're using concourse. And so we'll have to unpick a little bit of that. So you've got pipelines and pipelines collect everything. They collect all the other things like resources, jobs and tasks. And they can represent like a unit of work like we've got a delivery pipeline. We take some stuff and we get some stuff and in the middle there's some doing of things. We've got resources and we've got jobs. Resources are like, concourse wants you to put your state somewhere else and it wants you to reason about your state. And what do we mean by state? We mean like code or we mean release artifacts, right? We don't want them to be on our concourse server or on our build server. We want you, the pipeline user to have your code somewhere like object storage. Concourse won't, will not let you say this lives on this VM. You have to say it's going to live somewhere else. That's how we can get like this safe distributed system. Jobs on the other hand are stateless. They interact with resources. They say, I'm going to take your state and I'm going to move it around. So like I'm going to do things to transform that state. But I could run on any one of the like machines in this concourse cluster. And then a job is, well, that's a job is composed of tasks which actually do the things to the resources. Let's kind of go a little bit more into technical detail, right? Usually when you think of the ICD pipeline, do you think when this is triggered, then this pipeline is going to run? That's not how concourse thinks. Concourse is like a pipeline is a direct acyclic graph, which means I've got a bunch of nodes and edges between them. You don't just read a concourse pipeline like left to right kind of because smaller parts of the pipeline can trigger. Whenever they want, right? We're more talking about a flow. And a pipeline is written in YAML and you apply using a CI tool, CI tool. And concourse kind of like thinks about the pipeline when you're thinking about the web UI, when you want to look at something. It automatically generates a web UI so you can see what your pipeline looks like. Jobs are kind of how you're going to organize your resources and tasks together. And they're composed of a series of steps that have useful abstractions for how you build your processes. So you can say, let's do these things in parallel. Okay, now we've done those things in parallel. Do these series of steps. Oh, I've got a step here that isn't critical so we can skip it. And a task is like an interaction with a resource or it's doing a thing. That's what step is. A task is actually doing a thing. So it's like, I'll run this script or I'll like pull down like, well, just run your code basically. It's executed in an ephemeral environment and you have to specify the image. Concourse will manage the OCI images that you specify. So I want this to run within the context of Ruby 2.6 and it will do that. So you can't, and this is really useful for operators because if I provide concourse as a service to like 200 people in the org, I don't want to manage change requests saying like, hi, can I have an agent with like Ruby 2.6 on it and another agent with Ruby 2.4 on it. And you will see patterns when people use, like when the workloads of your CI system are not abstract, are not abstracted into like how the user thinks about like using the service. They'll say like, I need you another team to like install this software for me and we don't want any of that. The flow control within a job is like, this is what a step is. Let's say we want to run, I want to download all this stuff in parallel and then once that's done, do this in series and then I maybe want to execute this code. But if the code execution fails, it doesn't matter. You can get concourse to update other concourse pipelines dynamically, which means you can like get a pipeline to coordinate other pipelines, which is really neat. And then on the right, we've got resource interactions. So we've externalized our state, how, like, what are the operations associated with talking about our state. So in the background, concourse will check for resources as they're updated, as they change, and that can then lead other bits of code to execute somewhere else. And this will make sense when we go through an example. And then getting resources like giving that state, putting resources like the stuff that we just did locally needs to live over there. So some examples of what a task is going to do is going to be like, I've got this code in this environment. I want to build that into a container image. Or I've got this code. I want to generate a release artifact like a binary. Or I've got some code. I want to run some tests on it. Or the difference between this commit or this master branch and the release that we're about to cut are these commits. Let's generate some automated release notes so that we can send out a release and it will make sense. And you and I don't have to sit in the release email and be like, we've generated these release notes by looking at the commits because why? And then we've got some resource types. We've got some state in the world. But what is that state? That state could be an image repository for a container image. It could be your code in Git. It could be a file in object storage. It could be a semantic version that you have in object storage and you want to like manage the semantic version. So when the semantic version changes, execute this pipeline or when this Git repo comes in, we'll build the code, test it, push the release artifact, then bump the semantic version, and then other pipelines will trigger off of that. Additionally, lock on lock or a pool. Come back to this later. But then also, like what is state? You could have a terraformed deployment as a state file as a bit of state in the external world. Conquest will check when that changes and that will trigger a new pipeline or Cloud Foundry app. I've got my code or push it to Cloud Foundry when my app changes in Cloud Foundry, execute this pipeline. So this is an example of what a Conquest pipeline looks like. We're getting in some code on the left. We're going to run some tests on it. If the tests pass, then we're going to deploy it. And along the way, we're going to do some bookkeeping. We've got a multi-environment continuous deployment, right? All the way on the left, it's kind of hard to see. This is why in the Conquest UI, you can zoom in and see what's going on. We've got a build step and then we've got three identical environment release steps where we're saying, here we go, deploy it to preview, run some tests, cool. All right, deploy it to staging, run some tests, cool. Move on. We've got a branching pipeline. So this is where we can start to see the difference between triggering and non-triggering resources. We've got my code repo, which has some code in it. And we've got some lines going into these jobs over here. Like tests would go 1.1, tests would go 11, go 12, go 13. And we're going to pull in the container image for those things so we don't have to do a build step every single time. But when the images change, there's a dash line between go 1.11, but there's a solid line between my code repo. So the build is only going to trigger when the code repo changes. That's what that means. And you can automate a manual release process. And I'm using the word automate from this really lovely book, Toyota Production System, which is talking about how workers inside a pipeline can engage with machines in a human process. We're making decisions about how we're going to release software or manage a software release process or some other software production process. But we don't have to make it fully automated. So we've got this command line tool at work that we distribute to everyone in our organization. But we only want to generate a release when it's going to actually make a material improvement to someone's life, like a bug fix. It's just us doing development, right? We don't want to cut that release every single time. So this is quite an interesting pipeline wherein when this semantic version changes, we're going to do this build step and it's going to generate a draft release in GitHub. But this will only kick off once we've triggered one of these two things which will either bump the semantic version by a minor version or by a major version, which means I can, you know, talk to one of my colleagues. Do we want to release any version of this? Yes or no? All right, we'll go and bump the version in concourse and it will go and do its thing. I think a lot of the time in these sorts of, like, when you're collaborating on a project, sometimes it falls upon the burden of the maintainer to manage a release process, run a script and all that stuff. And it can either be extremely draining for that person or it can be like a blocker to delivery. And when you're able to, like, express that in a pipeline, like, express your process in a pipeline instead of just going through one single person, then that's beneficial. So let's, we're all YAML engineers. It's 2020. Let's do some YAML now. So we're going to continuously deploy to Terraform. When Terraform and Git repo changes, we want it to be continuously deployed. And that pipeline is going to look like this. When my code repo changes, it's automatically going to trigger this deploying my code job and then that's going to update my Terraform deployment. So when building a concourse pipeline, you kind of want to think about human names, like, what does this mean to me? And then what is it doing, right? Resources, what is this? Jobs, what is it doing? So we've got our code. I've got my Terraform deployment and I'm going to deploy the code. So this is how you configure a Git resource. We're saying it's a Git resource. And it comes from the develop branch and this is its URI. This is my Terraform deployment. It's a Terraform resource. And then there's some configuration for that, but it's like state bucket and things like that. And then we're going to, this is our job. We only want to run one Terraform deployment at a time, which is why it is serial. And the plan is get my code. When my code changes, we're going to trigger this pipeline. And then we're going to put it to the Terraform resource, and that's it. So that's our pipeline. This pipeline will deploy Terraform changes whenever the develop branch changes. And this is a configuration for, so we're saying, the state file lives in this bucket. And here are access keys. And concourse will manage credentials, or it will delegate the management of credentials to credential providers. This is Amazon's simple systems manager. Kubernetes, Vault, et cetera. So when these credentials are needed, they'll be pulled from the credentials provider and used, which is quite neat. And then once we've done our pipeline, we will then apply it, set it. It's going to run. Yay. Cool. Go us. Oh, no. A common pattern within organizations once you adopt continuous deployment is people don't look at pipelines because they expect, I've merged it in Git, it will now work. And sometimes it doesn't work. So let's add a Slack notification if the build fails. So we're going to say, our Slack channel is a resource that we can update. It's a Slack resource. And then when our put step fails, as in the Terraform deployment fails, we want to say, in the develop channel, airplane says build name failed, check it out and then whatever message you want to send and then various different bits of context to pass those environment variables so you can get a contextual notification. And that means it looks like this, which means if our Terraform deployment fails, then we can apply failure notifications. So if you want to build your own resource or you want to extend concourse in a way that a resource doesn't exist for you, you have to write drop note. No, you don't have to write any Java. Concourse is a Go project, but the way that you extend it is by saying look at image or any other compatible image and you have to implement three different executables, check in and out. Concourse will execute check periodically with some credentials if you need any credentials and then you're going to emit a list of resources, a list of versions. In is when you're pulling in stuff, like you're populating the local state and out is when someone puts, is like here's some stuff, wherever the state is living. Here's another haiku. Let's talk about gov.uk powers and how we use concourse. When we're releasing powers, we care about our users and so we want to say things like I want my applications running on my platform to be four nines available and I want my API to be three nines available and we want to encode this in our pipeline so that no one can release code without like meeting these objectives and this is what our pipeline looks like. Oh no. It's a bit scary because you've just joined the team and there's a lot of stuff going on but it's fine, we're going to go through it. So the first thing that we want to do in certain steps in the pipeline is we want to lock and unlock and we want to say nothing else is going to change this while we're doing these steps. Locking is an explicit thing because you don't want to lock things unnecessarily because then you're just slowing down your development process unless you absolutely need to. We're then going to generate some configuration like some secrets or we're going to generate some certificates that are going to be used later in the platform rather than in concourse. We're then going to wait while we're starting our availability tests which live at the end of the arrow, those two little boxes. We're then going to run Terraform. Once Terraform is finished deploying, we've got our network, we've got our VPC, we can start to do things, we can start to deploy VMs and software. We're then going to deploy Cloud Foundry using Bosch. Once Cloud Foundry is deployed, we're going to deploy some other things using Bosch and we're going to deploy some service brokers and configure some users, just general little bits of things that concourse will manage for us, things that usually you would have as a script. Then we've got a whole boatload of tests and we've got some other apps here that are deployed. The interesting thing about these apps which is these apps aren't affected by the locking process which means if we're just deploying some other miscellaneous microservices they're kind of fast-passed to production. Each of these jobs contains the getting of the resource, the triggering, the deployment and then running the tests. Then we're going to do certificate rotation. In a platform we've got maybe 200 CAs to rotate. Every component has a CA and everything else has to understand and trust different component CAs. Every time we run the deployment pipeline which we run multiple times per day, we'll check which parts of the certificates need to be rotated and then we'll do a few steps in the certificate rotation process. Next time things deployed, everyone's certificates trust everything else and so no human being has to reason about certificate rotation and this is one of the really useful things that we get from Bosch and Credhub. Then we get tag our release to say this is a good release and then we're done. Now let's do it again because we've deployed one environment. We've got a couple of production environments and so we're going to do this. We're going to say when staging finishes then we've got our git tags down here that say I've got a new thing to release so let's release it and then the production pipelines will run but in production. Normal deployments are fully automated, right? Every time you merge it will get deployed. Sometimes this deployment pipeline will take four hours because you've rotated every single VM in the cluster and sometimes a deployment will take minutes just waiting for our tests to run and deployments like there's no overhead of having a deployment, right? You're in the CITD endeavor and you're probably invested in some sort of continuous delivery process so that makes sense and deployments will fail safely. We've got the locks, we've got some tests. If our deployment pipeline says no during staging we didn't meet our availability expectations then a human being can either say I'm going to override that process because this is a critical security fix taking less availability or we'll say all right let's reset staging to what production is like dig into the root cause, nice and Bosch does a lot of work here. The UI is anger optimized, right? Like concourse generates this for you and it's like look this is why your pipeline is red like it's red here, dig in and then you click through these and you'll get all the contextual logs. It's visually obvious, like I'll get work up at three in the morning maybe oh this has failed and now we can talk a little bit about how we integrate with the Grafana so when we start and end our pipeline we put an overlay over our Grafana dashboards so we can see what was our like HCP 500 rate while we were doing this deployment and this is really useful contextual information for like what has changed, right? I'm in my monitoring I've got I've seen the alert what has changed and it's like well deployment happened and then we instrument each individual pipeline with like when are like each individual job to say what it's doing so if we see like an elevated 500 rate for a small part of the pipeline we can be like oh that's when we are rotating this certificate or that's when we are really pulling this thing which is really useful so this is our code it's running in production we've been running it production for like five years some of it, can you reuse this? Yes, you can so there's a microsite called resource types which is available on the Chronicles website where we share all of the resources that are resource types that people have set up so forget resources there the Terraform resources there there's some like Kubernetes resources that you can go and have a look at so sometimes you'll be like oh I want to automate this process has someone made a resource for it and they will have and then you just use that and contribute back, be good open source people fix other people's bugs so now we can talk about some of the patterns that we've gone through in this pipeline locks, pools, counters, some tests some metrics and annotations and sort of like as open source maintainers how do we automate release processes, how do we automate communications so like I'm not sitting in my email for two hours when I could be writing some code so pools and locks right this is the bit where we're locking the pipeline a pool is implemented as a get resource and it as like a get repo and it controls like who controls what resources so you could say only one pipeline is allowed to reason about staging at any given time well only one pipeline there are only five environments that we can have so we only deploy five things and if you're waiting for a lock you have to wait for someone else and then you can automate or you can provide some controls or some like dials for operators to use you don't want to be like typing error prone commands into your terminal to unblock a release pipeline make that automated, make that all set up and we use this in our release pipelines all the time so we've got this lock here, here's your like in a documentation or a run book page like if this happens run this job if this happens run this job but for the most part make it automated availability test so we implement these as a task and we use this wonderful library called vegeta to do um like vegeta attack or to do some load testing to work out like are we getting an acceptable rate of errors is our error rate too high and we've got some a little bit of go that uses this as a library to implement that and this is a really really useful pattern that's like sitting down and be like what do I want my users what expectations do my users have of my service and how can I make sure that they're going to get that level of service and then putting that in your pipeline instead of being like oh I hope it's going to work annotations so this is a resource that we wrote it's the Grafana annotation resource you put to it and it'll put a line on your Grafana dashboard and then if you put to it again it will draw a window over your Grafana chart so this is the example from earlier where this is our deployment overview and it's drawn a line over a two hour deploy um metrics so concourse exposes metrics or sends metrics to your metrics aggregator of choice a lot of times you'll have like a smoke test in someone's production infrastructure you'll have a smoke test that will run every five minutes to check that the service isn't down and then if it fails it'll get woken up and then at one point in time that smoke test will become flaky and then someone will wrap that in a for loop and then no please don't do that instead we have all of the metrics all of the jobs exposed as Prometheus metrics so we can reason about a pipeline as a time series we can say when the rate in a 30 minute period our smoke tests haven't succeeded then something's wrong and then alert manager will call us or something like that look at concourse.ci.org metrics for like all of the supported metrics aggregators we use Prometheus it's really neat for this the other really useful thing about having all of your builds all of your pipeline runs as metrics we can do things like how long does this pipeline take to run for like ever but you can slice and dice that with like well you know which tests are flaky and there are plugins to do that for other tools right but for concourse it makes sense to think about as time series like this for us release management so this is another example shown earlier like how do we collaborate how do we take what we like our and translate that into a workflow we can use through a concourse pipeline and this uses two resources the Senva resource which knows about a semantic version so you can put to it with a patch or put to it with a minor or a major and it will work out how to represent that in file form so you can then say oh well I want this to trigger when there's a major release I want to trigger this when there's a minor release and we use GitHub release resource because we host our release artifacts on GitHub for this CLI tool in particular and what this will do is it will look at all of the commits since the last release and generate release notes for us and then all we have to do is go into GitHub maybe write some thanks to our contributors and then click publish instead of publish this draft communications like don't rely on watching your pipelines yeah you want it to be automated you want everything to tell you when it's wrong like we shouldn't come in and be like oh like I have to look at a dashboard because it's red like none of that please there's a page review resource that will call you if a job fails you can get it to do Slack and HipChat there's an email resource and I think there's an ILC resource so you can get concourse to post into ILC that's concourse concourse is an open source continuous thing doer there's a really really wonderful quick start on concourseci.org that will set up a concourse to you running locally so you can play around with it and there's a really really vibrant open source community around concourse so I encourage you to check it out that was my talk any questions I think we've got three minutes can you as a result for some testing update that will take a free run to change so the question was as the result of something can you update the configuration so if it changes so depending on what that result is will depend on how you go about doing that process you could say when this changes I'll reconfigure the pipeline that's the perfectly reasonable thing to do in concourse I think it depends a lot more on the specifics of what change you're trying to achieve for me to fully answer that question but you can send me an email if you want to get into the specifics yep in terms of the resources today does the PAS care whether it's like a Docker container or CloudFoundry or anything like that so is this a question about GovDK PAS or a question about concourse more about your PAS yeah so this the question was does GovDK PAS care about if it's like what the code artifact is and CloudFoundry not just our PAS but CloudFoundry specifically is able to deploy Docker or just code and it has a build service using a project called BuildPacks to build your code for you into an OCI image so your developers don't need to know about Docker or something like that any other questions yep for unit testing the platform or in a pipeline yes so if we go back to this example here all the way back so in this deploy let's find the skeleton here so in my Terraform deployment if I wanted to run a unit test in this jobs section down here I've got my code if I said task run unit tests and then I would say I want to run this unit test in the context of Ruby I want to execute bundle exec aspect and so we use it for running tests on our PRs sometimes you'd want to say when this pull request changes clone the code, run the unit test sometimes you don't want to do that there are other solutions for doing like CI within the context of a pull request but you can use concourse for running unit tests I think it depends on like what kind of dependencies you need in your tests like do you need a Postgres database in MySQL you can do that with concourse but it's a little bit of a hassle I think we're out of time so if anyone has any questions I think it's probably best to send me an email you can send me an email just go to my website my email address is there I know that was quite a lot of content the slides are on fosdm.org on the talk and if you have any further questions send me an email thanks very much