Perfect. Hello everyone, good afternoon and welcome. My name is Navin Joy. I'm a cloud architect with Cisco. And my session is about an introduction to cloud service definition. Since this is an introductory session, I will not assume that you know any background material. So we'll start off from the basics. And at the end of the session, I will also show a demo. So I have OpenStack Kilo release running on my system here. And we will deploy some of the artifacts and to illustrate the concepts. You will see the template being orchestrated and the stacks being created. So on the agenda today, we will talk about declarative modeling, what that is. We will look at the service definition language briefly. And I will walk you through a real world scenario, pretty realistic. Some of these scenarios that I worked with my customers to deploy services. We will look briefly at the template structure. And we will start from a conceptual service model, which is a diagrammatic representation of the service that we will be deploying. And from there, we will translate into a template-specific representation that is suitable for deployment. Then we will look at some minor details for service definition that will help us understand how these various resources are connected and how that template is being composed, very high-level requirements. And finally, we will do the live demo if everything works. Basically, go ahead and create the stack and see the output. So let us look at what a declarative approach is. So in the declarative approach, you primarily describe what should be accomplished and not exactly the details of how to get there. Essentially, you think like a manager, like who is creating a high-level plan without the details. And then you let somebody else, like an employee who is working for you or some specialist, figure out the details. So in this case, the manager is going to be you and the person working for you is the heat service. So what you are going to essentially do is to create a description of your infrastructure or your application architecture in a language that your service can understand. And then what you're going to do is to send that description over by an API call to the service. And the service is going to parse all the details and it's going to do the various analysis inside and figure out what resources you want to create. And then it's going to go ahead and make all the necessary calls to the OpenStack services such as NOVA, Neutron, Cinder, and so on and so forth. And then finally, it's going to deploy that service for you and then it's going to report back on the state of that service. So that is the, in essence, the declarative modeling. So all you need to know is the high-level description of what you want to accomplish and the service is going to figure all of that out. So now this is key is how do you describe services? So there is a language called YAML. It is designed to be a human-friendly readable language. YAML stands for YAML in markup language.  You can read it easily. And in order, since I'm not assuming any prerequisites, I will give you just enough knowledge to be able to read a specification. So all you need to know is these three bullet items. So if you want to list items, you can either use the familiar square brackets or you can use a dash and a space. So if you want to do key-value mappings, you can use a colon and a space representation or the curly braces key colon value. And you always use indentation to define scope, basically to tell when a list item ends and the other list begins. So you will see that. Let's look at the scenario.  So a company has deployed OpenStack with orchestration service and they want to simplify application deployment. That's the goal. And they have two key requirements. The first requirement is to create a repeatable configuration for the infrastructure. It's important to know that this is just a configuration. When you create this repeatable configuration, the actual resources are not created at this point. The second is the instantiation of the configuration. So if you are familiar with object-oriented technologies, you create a class. At that point, your object is not created specification. And then when you instantiate it is when the actual object is created. So similarly, you create the configuration and the instantiation of that can be done in a predictable manner. And who does this instantiation? That's the service. So let us go from the requirements to concepts. The first requirement was to create a repeatable infrastructure configuration. So that translates into the YAML template, which also functions as a specification. The second requirement is that you have to be able to create unique instantiation of the configuration, which translates into a stack. And stack is a set of resources that you create and you manage as one unit.  So if you want to add a new resource, so if you want to modify resources, you modify the template and send the modified template to the service. And the service is going to figure out what changed and it's going to make the necessary adjustments. So the instantiation is called essentially the stack. Now here is a description of the high-level service that we will be deploying. So the service has two components, component one and component two. Each of this will be modeled separately. You can create repeatable instantiations of both of these components separately. The first component is called a virtual private cloud, which is an isolated section of the network. And as shown in the right-hand side, you have an internet gateway that is represented by a router connected to an external network. And the router has two interfaces to two inside networks. And the component two is an instance with a volume attached to it. It's very straightforward. And we have also defined runtime parameters. And these runtime parameters are used to customize the stack deployment. So every time you create a unique instantiation of this particular service, which is a component one or two, you can provide different values for these parameters to create a slightly different flavor, if you will, for that service. So for the first service, we have created network name and subnet blocks at the parameter, in which case as you instantiate it at runtime, you can provide these values. Similarly, for the second component, we have specified SSH key, image, flavor, volume size, and the network to which you want this app to be deployed. So this is a high-level model of the service that you want to create and deploy to OpenStack. Now let us briefly look at the template structure. The template has five sections. The first section, of course, is an input section in which you specify the parameters. And there are two sections that are pretty self-descriptory. One is the heat template version. And heat uses that to determine which version of the template you're using. The second is a description. You can provide anything that describes your stack. And in the resources section is where you describe all the resources. Remember the declarative modeling where you primarily describe all the resources without the details and let the service figure all those details for you. So this is the key section that is required, resources in which you pretty much describe what you want. And the output section is basically the values to be returned after the stack has been created. For instance, you may want the IP address that has been dynamically assigned and then you want to get that value after the stack has been created and pass it on to a different application or things like that. So you can ask the stack to return certain outputs. So this is a conceptual model for a VPC service that we described earlier. So in this model, you can see all of those three sections. Parameters have been identified, resources and outputs. And the arrows show the dependencies. So here you can see that each resource is assigned a unique name, otherwise known as an ID. So we have seven resources. What essentially we have done is the network topology that you have seen in the previous slide has been taken and broken down into resources with each resource assigned a unique name. So you can see we have networks and subnet. And there is a relationship between the subnet to the network. So you can see subnet 1 is dependent on the network, which means that the network has to be created first before you can associate a subnet with it. And heat is going to look at all of this. It's going to resolve these dependencies and execute the creation of these resources in the correct order. Similarly, if you look at the parameters section, you have four parameters and these parameters are used to customize the stack. Every time you create a deployment of the service, you can adjust the values for the parameters to create something unique. For instance, you can create a first time when you create an instantiation of the service, you can assign different names for network 1 and 2 and different subnet cider blocks. So that will create the service in a unique manner. And similarly, we have modeled the MyApp service, which shows the instance volume and the attachment and the dependencies between those resources. So you can see the volume attachment requires the volume and the instance to be created before you can attach it. So heat is going to do that dependency mapping for us and then execute make calls to NOVA and Cinder to be able to create all of these resources before it actually performs attachment. Much like how a human being would do, heat will take care of doing each of those operations independently and keep all of that resources created together in a stack. And the left-hand side shows the parameters. So we have identified, so each time you deploy this template, you want to be able to provide a unique key, image, flavor, the network to which you want the app to be connected to and the size of the volume. And finally, from the output standpoint, you want to get the instance IP as an output because that's going to be assigned dynamically by DHCP, at least in this scenario. So once you create this conceptual model, the rest is going to be easier because you can take this and translate it into a specification and then send that specification to the service, which will deploy all these resources. So just in order to define the dependencies, you will need to know just these three items to be used. One is the getResource function that you can use in the template. What it does is it references another resource. So use getResource and a resource name, which says that resource A, when it uses this function, it references some other resource, so that dependency mapping is there. And getParam is the function that is used to reference an input parameter. And getAttribute references a resource attribute. So why do you really need these functions? Because values for these are determined at runtime. So that's why you tell the heat engine to say, for instance, when you create a subnet, if you want to associate that subnet with a network, you will have to provide a mapping from the subnet to that network. And since that network doesn't exist yet, you want to be able to tell it, use this getResource function to get the value of the network that you have created at runtime and use that to map the subnet. So since this is all runtime operations, you tell heat to execute the correct order or the correct dependency or use the right input and get the right output using these functions. So this is just a brief overview of how these functions are used. And you can see that in this resources section, we have defined three resources, network one, two, and a subnet. And in the properties section, under the name property of the network one, you can see that a getParam function has been used to reference a parameter named network one. What this tells heat is that when you deploy network one, the name of the network should be obtained by looking up the value of the parameter named network one. Similarly, on subnet, you can see that the network ID references a resource named network one. What that tells heat is that when you create the subnet, the network ID has to be referenced, has to be obtained from the resource named network one that it has created. So all of these, so this is just a snapshot. So all of these YAML files are available for you to download. I've posted it and you can download, play with it and create your own stacks and examine it. So feel free to extend it and use it. So now we will go to the demo in which in the first step, we will create a virtual private cloud by deploying the vpc.yaml template. And in the second step, we will show the repeatability by creating another virtual private cloud by deploying vpc.yaml again the same template with different parameter values to create a unique flavor for the virtual private cloud. Then step three is we will deploy the app to the virtual private cloud and then attach that app to one of the networks. So I'll switch back to my demo environment. So I've logged into the open stack release which is a kilo release that is running here locally as a VM. And now I'm going to the orchestration service. When you click on the stack, you'll be presented an option to launch a stack. So you click on launch a stack and it will prompt you for the template source. What this means is that it is asking you for that specification that you have composed. So you choose a template file and since we want to deploy the virtual private cloud, so you choose vpc.yaml. vpc.yaml essentially contains all of the dependency mapping. It has that router with attached to the external network with two interfaces connected to two internal networks. So that is the topology that we have defined. Then the environment source is you can either provide the values for the parameter either using a file or you can type it in manually as in the next window. But in order to better present it centrally, let's use the file-based approach. So I have put all the parameters and mapped it to a value in the vpc.yaml. So now when you click next here, what happens is that it's asked for a stack name. Let's name it vpc1, provide the admin password and you can see here that the parameters earlier on that have been defined in the template are right here with these values, rednet. So we are deploying two networks named red and blue and two cider blocks. All of these values are provided at runtime in my environment file. It has been picked up from that file. And another cool feature here is that you have the ability to roll back the stack on failure. Let's say when you are deploying this whole stack, heat finds out that the virtual machine cannot be deployed. There is some error because let's say you ran out of memory and at that point instead of just keeping that stack in an inconsistent error state, if you check rollback, heat will automatically detect that now I cannot create, I cannot realize the specification. So let me go ahead and roll it back. It will go back to the clean state. So that's a cool feature. So now just to go back to the virtual private cloud, it has two networks named red and blue and two cider blocks. All of these are runtime values that you have specified here. So now when you hit launch, at this point what happens is that this specification has been sent by an API to the heat service and heat service is figuring out that it has to create those resources and it has gone ahead and created it. So now it says create complete. It's a good thing. So let's go to the network topology and look at the service. As you can see, a virtual private cloud has been created with a gateway router attached to two networks named red and blue and the correct subnets that we have provided have been used by heat. So in order to illustrate the repeatability and how easy is to create this model, let's go ahead and deploy the same template again but provide different values for input parameters such as different cider blocks, different network name and see that an identical model that is highly predictable, exactly the same model has been created. Go back to stacks. So you have one stack. So I'll launch the second stack and so I have not changed the architecture. The architecture is in the same VPC YAML. So I'm deploying the same YAML file but with a different environment. Let's call the stack VPC 2. So here you can see that the input parameters are red net 1, blue net 1 and a different cider block. So now when you launch it, heat now goes ahead and creates a stack and it's in progress right now. So it has created it. So let us look at the stack it has created. So now we can see that an identical representation of the virtual private cloud has been created again in a very predictable manner. You can see another router attached to two networks, red net 1 and blue as you have specified. All you have done now is to once you have defined your application or once you have defined your network architecture, it's easy to create repeatable instantiations in a highly predictable manner by just using your template file and then changing the parameters. So you can create different flavors, different versions of it. So this is a very powerful concept. So otherwise what would have had to be done without this option was that somebody had to manually go in and create all of these things or write some script to do this. So all of those things have been automated. Now let us go ahead and deploy our application. So the application is modeled in the myapp.yaml file. It is basically a virtual machine with some storage attached to it and then at runtime we will specify what network it has to be connected to. So myapp environment, let us call it myapp1. So all of the runtime parameters are right here and then we have specified that we want this particular application to be connected to the network named rednet in the virtual private cloud that we deployed first. And then we have also specified that we want one gig of storage. Now when we click launch, again here is going to do all the dependency mapping. It figures out that the network already exists based on the reference and then it creates the instance, it then creates the volume and then it attaches the volume to that instance. So it has done that. Let us now go ahead and look at the network topology. So you can see here that as we have specified the application has been deployed myapp with storage and connected attached to the rednetwork. So let's look at this instance details. You can see the flavor, flavor ID and it is attached to a network with the IP address that you have specified and then volume of, you know, one gig has been created and attached to that particular instance. So using this model you will be able to create another instance of the application and attach it to any other VPC. So in that way once you have two components of the application can be now easily customized and manage the way you want to. So that concludes the demo. Let's go back to our deck. So now what you have seen is the declarative modeling approach where what I did was, all I did was to create that specification file and identified the inputs that I need to and then send that information over to the heat service and the heat service did all the real work for me like creating all the stacks and then I was able to just observe the output and see basically confirm whether it has been deployed to my specification or not. That's pretty much straightforward rather than creating all of these resources manually. So last slide and then I will open it up for questions. We have 10 minutes. All of the files, ML files, the local.conf if you want to create a stack of your own and this deck are available for download at this URL. Feel free to download. I've only shown you a small snapshot of the files but you can download and examine and play around with it and extend it as you want. So thank you. If you have any questions, feel free to ask. Yes, yes. So what, so within the template when I created the first network the network was called RedNet and when I created the second network I named it RedNet1. So when I created the application I specify the network and within the network I reference the RedNet of the VPC that I created first. The RedNet1 was the network that I created. So both are two different networks. So he figured out that I have to deploy it into the first VPC. The RedNet, okay, you can see that. Let me just go back if you want. I can show it to you. It takes a while. All right. So when I created the VPC, the first VPC it's even better to visualize here the network topology. When I created the first VPC I created RedNet and BlueNet. When I create a second VPC I created RedNet1 and BlueNet1 and when I created the application I specify that I want the app the instance to be connected to RedNet. So I can create another one and deploy to RedNet1. You can see that coming up. Any other questions? Yes, exactly. So all of the operations are stack operations. So if you want to modify this stack you will have to modify the template. So you go ahead and take the same old template change the RedNet to BlueNet or assign a different name and then send it down to Heat and then do a stack update operation. So there is, if you go to the stack section there is an operation here named changeStackTemplate. So you click on this and provide your modified template and in the modified template you just modify the resources that you want to change. The Heat is intelligent enough to say okay I have all the so you have to specify all the resources in the previous template and only change the resources that you want to modify. The Heat is going to do a comparison and say okay this particular resource change let me go ahead and change it. So it will do stack operations and update it. It won't delete the stack. What it will do is it is going to look at the resources in the new template that you have provided and each resource has an identifier a resource name and the properties. If the resource name and the properties are the same Heat will say that you want to keep that resource it's not going to delete it. If you delete the resource from the stack and update the stack to the Heat send it then it will say okay you deployed Network1 before now you don't want it it's not present in the stack that is how it infers that you want it to be deleted or if you change the property of the network Heat will figure out okay previously I defined created the network as RedNet1 and now in the new template you have specified let's say BlueNet for the same network it's going to delete that RedNet and create a different network. So it infers it based on what you have specified in the template. Stack ID is going to remain the same. So if you don't specify a resource when you update the stack Heat will infer that you don't need that resource it's not going to delete it okay okay so okay I will repeat the question otherwise you can go to the mic so the previous question was how do you modify a stack after it has been created let's say you created a virtual private cloud and it has a red and blue network now let's say I want to change the red network to a different network right how do I do that the answer to that question is you have to create a different template and whatever resource that you want to modify you just update that in the template but leave the original resource that you don't want to be modified intact so Heat is going to compare the current template with the old template and figure out what changed and make the appropriate changes okay any other question yeah so the first question is is it supported through API or SDK yes all of these are API operations so what Horizon does here is that it makes an API call this using the heat client and then sends the template that you have defined to the heat service that is running at the back and so it's all API call this this is just a front-end representation to you and then it is going to pull and retrieve the stack update from the service and the second question was is it supported in kilo release yes I'm running a kilo release but in the previous releases previous releases are not quite stable yet personally I wouldn't recommend it at least Juno should be fine but not beyond before that yes that is possible so the question was can you create dependencies between the my app and VPC essentially what we did was to create a dependency here so let me now if I go ahead and delete VPC one there is an error it won't allow me to do that if you go ahead and delete it it will say cannot delete it it will fail see delete failed because it delete failed because of the dependency mapping my app has been connected now to VPC you can't just delete the VPC so that dependency is created as soon as you deploy the app so if you want to delete this VPC you have to first go ahead and delete the application delete stack it will clear out the application and then you can delete the VPC yes so here is the hand first yes so I have been in fact involved with TOSCA so TOSCA is a very application oriented definition of the language whereas this heat is largely an infrastructure level representation it is not directly support TOSCA to heat what you can essentially do is you should be able to write a translation or some sort of a program that can take a TOSCA's and convert that into a heat representation you may have to break down some of the components when you say in TOSCA MySQL you may have to either create a heat resource which is compatible with that in heat you can create a specific resource your own resource and then specify the properties for it so you will have to do all of those mappings before you can deploy a TOSCA template so it will require some work but it is doable I think it is a good exercise there was a question oh yeah so that the reason is actually in the heat logs so you will have to look at the logs to see exactly it will tell you that it delete fail because of the exact specific reason yes so the question was is it possible to manage OpenStack services OpenStack services okay so services outside of OpenStack using heat you can in fact heat is plugable so it will require you to write some heat plugins and then you know make that plugin to manage that external resource that you want to manage maybe if you want to manage AWS VM creation or a DHCP service or something other it is very much possible so you will have to write a plugin and then heat will use that plugin to manage that external service okay there is one more question so the plugin to extend the capability of heat is unfortunately not in this introductory session maybe I can have probably in the next you know OpenStack an advanced session to illustrate that capability so yes it is possible it requires some work and in fact a few people had demos here showing exactly how that plugin was written to manage an AWS resource you know you can watch the session video too because that is more of an advanced concepts okay any other questions yeah IBM yeah so the question is can you explain how a service chaining works and how IP address is assigned so the point here is that when you create that specification right you are defining it depends on what you are defining as a services first I deployed in my case VPC was the first service right and I deployed that VPC service so I deployed it manually to keep it simple so there is another option called chaining of these templates that is a more advanced topic where in heat you can specify you can actually link or compose one service inside another so in which case it's kind of service chaining you can talk you know you can describe it in any way their template composition or whatever that is I view that as service chaining you can define different services and change them together and create a larger template so that is also possible more advanced topic in heat I think that's in kilo release they have started off with it but I would like to see some more improvements before using that service chaining or template composition and production yes okay the question is HP and Huawei had made a similar proposal and whether I had any intentions of combining so here this is not a proposal this is an introductory session to heat where I'm basically my session really shows you the various capabilities of service modeling declarative modeling concepts right this is not something that is totally new this is there in heat today the what I work I did was basically tie things together into two services two specific concrete services that you can deploy that's all this is not a proposal of anything you know this is just basically an introduction to how you can create and manage services in heat so I think we are out of time 1242 so thank you all appreciate it


OK, but the normal stop time is 10, 15. OK. Yeah, that's cool. I'll try to keep it on track. Yeah, all right, cool. All right, sweet. So falling Dan's is going to be hard, because he was awesome today. He was on fire. But I'm going to dig a little deeper into a lot of the things he talked about, but just go a hair deeper into the standards and how they work and why. And essentially, if you think about it, backing up and thinking about it as a whole, the problem with the industry is if we don't have a standard, you can't consume, for example, a perfect example is say you want to use a registry server to Amazon. Say you want to build locally, build an image, push out to Amazon, push to Docker Hub, push to your own built-in registry. You have to have a standard that everybody can comply to so that you can have true portability. Like the idea of the cloud, right, is I can move things back and forth and make it easy. And so it's a mixture of products provided by companies, community projects created by individuals and communities, and services, essentially, that are also by products, or by companies. And so if you don't have that, you have bags, box, barrels, and crates, as I used to say. They're all different sizes, and trying to put them on a ship, you have to stack them all. And so really the idea, literally the good analogy is basically shipping containers. And people don't think, this is a conversation I've had a lot. In fact, this week I had it with the SyLabs guys, the guys at De-Singularity, because they have a different format, and we were discussing where should they plug into the ecosystem, right?  Like do I build to the CRI spec? Do I build to the OCI spec? Like where do I fit in, and where don't I fit in? Should I use the Docker CLI? Some people have integrated with the Docker socket, things like that. And you end up in dangerous situations where you're like the world moves and tectonic plates shift, and then now your stuff doesn't work right, because something broke with a version change. And so really what I want to dig into in this talk is kind of like, where should you integrate? Where do these standards protect you? Where don't they protect you? What do you really get from all these? And I mean, Dan did a great job, because we've built an ecosystem of tools around, would build a scopio, podman, that actually work using a lot of these standards. So we have a lot of expertise in figuring out where these things should fit and where you can invest long term. And so to have this healthy ecosystem of things where people can go off and innovate and do things, but then lift their head back up, and their tool still works in the ecosystem, you pretty much have to have well-defined interfaces and well-defined standards. And so I'm going to dig into about five of them, actually. So the solution, like I mentioned, is open standards. You have to have well-defined interfaces and open standards. And so you need to be able to have this happen, right? I need to be able to swap any one of these out in certain places, right? Like the world started with Docker, they invented the concept of a container engine, at which yesterday I talked about is really basically a giant proof of concept, right? That word Docker means so many things. It's a company, it's an API, it's a demon, it was a format for images. It was also an ecosystem of images out on Docker Hub. And the only way to kind of sell the world on how to do containers in this new way was to kind of build this giant proof of concept. And that was the genius. But the downside is now four years later, you've got everything munged into this giant proof of concept. And that is bad, because it's really hard when you want to make a small change, like the damn brought up example of Rocket wants to integrate in Kubernetes, but Kubernetes is hardwired to Docker. That's a bad scenario, right? Or you want to have a standard spec on what images they pull, obviously. So we've chipped away at different pieces of this to make it so that these things are plugable. And now today, 2018, we're actually in a really good spot where you can plug these different things in. And essentially, every one of these does the same job. And I'll dig in deeper and where they all fit in and why they work. So a long time ago, several years back, I went back and kind of revisited the original, like four years ago, four and a half years ago, whatever that was, when Docker first came out, a lot of people made the shipping analogy, right? And I actually went back and dug into some of the ice up standards around actual shipping containers, because they're apropos to the software containers. And one of the ones that were actually really interesting to me was ISO 1161, hook dimensions and strength. So I just pictured, right, there was some point in history where some guy was operating a crane, trying to lift the container and the top tore off. And who knows, the container fell out, and all the stuff fell out everywhere. Because nobody had ever standardized, like, what is the strength, the potential strength of the corners and the hooks, and things like that? And really the same, we went through that same process in containers in that now we have an actual standard for what the images look like. And this also highlights not just the image, but the tooling, so the cranes. I want to be able to buy one set of cranes that can move these containers around. I want to invest in those cranes, because I'm going to buy them for 30 years. And so the business problems that are associated with that become a lot more obvious when you're building physical stuff, because software feels like you can change it really fast, but in reality, nobody wants to once they put it in production. So you want to adopt a standard, because I still want to get value out of whatever I've built in five years or three years. I have some upstream stuff that I've built, and I'm lazy. I don't want to go change it just because something changed. I don't want to have to constantly rewire it. I just want to build to the spec and say, OK, it should work. So that's what I'm trying to highlight by making this analogy with the actual real shipping container. And so these are the five specs that I just want to dig into. And they're actually similar. I would say these two, on the end, are really well defined interfaces. They're not actually, or I'd call them, community-driven kind of standards. And then these are actually standards, body standards, these three. So there's a spec for images, like the actual image format on disk, and when you're moving around. Then there's a standard now, which is recent, for distribution. So that's like moving it between registry and cache or between registry servers, which is what Scopio works on. And then there is the runtime specification, which actually explains, and I'll dig deeper into it, but it kind of explains how you take all the stuff that's in the container image and turn it into a running process and all the translation that happens in between talking to the kernel. CRI does the same thing on the network side in a very similar way, except that there are pluggable binaries that can do the work instead of run C as kind of the standard that most people do, although it's pluggable as well. And I'll dig into that a little bit. And then CNI is what I'm talking about. And then CRI is really an interface between the Kublet and the container engine. And actually, that one came up the other day. I mentioned the anecdote of where should the SyLabs guys from Singularity, they have a really cool container engine, essentially is what they have. But they never were quite sure where they fit in and where they wanted to play in the space. And they play in HPC. And in HPC, they built their own image format that's not OCI compliant. So now they're kind of trapped in that world. But that's good and bad. It allows them to go innovate, and they can do things that maybe HPC users want. Maybe HPC users do want to ship the data around with the container image, which is what they do, essentially. OCI images do not do that. OCI images are just a code. The data lives locally. But the cool part is with CRI, two different groups can build a CRI compliant container engine. And then Kubernetes can just talk to it, or CRI CTL, which I'll dig into, to just talk to it. And you can list the images, see them there. Even if they're different formats, doesn't really matter. So the beauty of understanding these is that you can understand where your project should fit in, where you should build, where you can rely on things that you know that your stuff will work. And then as an architect, somebody building an environment knowing where these work, you can kind of know which projects you want to investigate. If I'm looking at a project, personally, I would be a little bit apprehensive if Singularity didn't comply to the CR interface, because there's probably places where I'd want to be able to call it through the standard interface. So I'm going to focus on CRI, CNI, and OCI. Those three main sets of standards, if you will. So I showed this slide yesterday, and it's the only one I'm going to show from my other one. But this is kind of the full money of what a container engine does. And I walk through it kind of, if you think about it, it took me a long time to boil down what is actually happening in a container engine. And I'm going to dig deep, deep into this in some future slides. But it's really a conglomeration of options that are specified in the container image as metadata, options that are specified as defaults in the container engine, user overridden options that they pass as command line options, or either that, or through YAML and Kubernetes, which then gets passed to the kubelet, which then gets passed to the container. But in a nutshell, it's image-defined, engine-defined, and human-defined options all get combined into something that then gets passed to Run-C, which is an OCI runtime standard, and then the CNI plug-ins, which are also binaries that take a config blob that's very similar to what gets passed to Run-C, but only for the network side. And so if you think about it, this is what a container engine does. And then on the far right side there, I show all the image layers come together, get smashed together, and in a nutshell, you can think of them. They're overlay. They're actually a copy-on-write layer added to the very end, which I won't dig deep into. But at the end of the day, just think of them as container image gets smashed down into a single layer that then gets mounted as a root FS. And again, then all these options come together, and that's kind of how a container gets ran. So now I want to, I talk about it like I kind of dig in a little bit deeper into where the standards play. So I showed you CNI, OCI runtime, OCI image, and actually distribution is really up there, too. I have an update of this drawing. And then here's where CRI works, right? So CRI is, Kubernetes is talking through the CRI interface to CRIO. So CRIO is a demon that it understands the CRI protocol, essentially. And you could plug in anything there instead of CRIO. In fact, there's commonly something called a Docker shim where it speaks CRI and then speaks Docker on the other side and then talks to the Docker engine. Container D has a new branch or whatever called container D-CRI that speaks this natively. As I mentioned, the Singularity guys are thinking about plugging in Singularity there as a CRI interface. So the cool part here is you could kind of see, since you're protected by, you're kind of, notice how CRIO is boxed in here. It's boxed in by standards on every side. So it's boxed in by CNI, the OCI runtime specification, the OCI image and distribution specifications at CRI. So you can plug CRIO in and out. There's nothing stopping you from moving some other CRI compliant slash OCI compliant demon in and out of there. And that's the beauty of these essentially standards. And then this was the one I came up with for Dan. He requested that I come up with the one that shows where CRI CTL and Podman come in. So this is a little bit deeper version that kind of shows, now there are some other things going on below the covers. So we have, at this layer, we have CRI interface. And that's kind of what defines the interface to the CRI compliant container engine. So whether it's a SHIM or it's natively supporting CRI, you can plug in or out that container engine. And one of the sides that you care about is the robots, Kubernetes. That's a scheduler coming in and talking to the container engine. But on the other side, we have something called CRI CTL. Think of this as the human interface to the container engine. And this took a while for it to click for me. But if you want to have a pluggable container engine, you need a standard API that robots can talk to. But then on the other side, you really need a utility that humans can become familiar with. So if I learn how to use CRI CTL, if I just learn how to use CRI CTL images and CRI CTL PS, you'll notice that the interface is quite similar to what Docker looks like, except for there's no run. Because it's assumed that with CRI interface, the KubeLit will be basically sending the runs to the engine. But in a nutshell, it's a pretty familiar command line interface. But you can now plug out that container engine pretty transparently to both the robots and the humans. And so that's the beauty of CRI, CRI CTL, and then KubeLit talking CRI to a CRI compliant container engine. And then one level down, many or most CRI compliant engines will be pulling OCI compliant images from OCI compliant registries through the distribution and image spec. The one caveat there, as I mentioned, for example, the singularity guys, they could plug in a non-OCI compliant where it goes and pulls its own container images that are a completely different format, which is fine. If that's what you want, as long as you understand that's what you want because you want some other value from that container engine. But then all rules below this might not apply anymore. But in the cryo world, this is what it looks like. So you can pull OCI compliant images. Then one more layer down, you've got container images and container storage that kind of mandate in a well-defined interface how things get laid out on disk and how the images get stored. And to look at that, you can actually do it like a CRI CTL images and see what images are cached locally. But if you want to tag images and play around with what's in the cache, that's where something like Podman or Builder or any of the ones that can talk to the local container cache. You can now go muck around with that stuff at a lower level if you want to. And then at the end of the day, though, as I showed in the last slide, everything gets handed to RunC. When it gets fired up, you're just passing it a root FS in that config.json to RunC. And then RunC talks to the kernel on a standard interface. And as long as the kernel features are there, those things get turned on, whether it's C groups, SeLinux, S-Fert, which I tracked down the other day and I have a whole deep article on that. And whatever clone arguments you want to pass, so whatever namespaces you want the container to run in, all that's defined in that RunC interface. All right, so what is a container anyway, though? I mean, I think Naolin mentioned he's going to go into this deeper. It's not rocket science. It's a black box, and so it's a little bit intimidating when you first start. And I have to admit tracking down a lot of this in the code and asking Naolin and Dan and a bunch of the guys on the Runtimes team different questions. I realized there was a class of people that understood what was going on under the covers. And it was like five, 10, 15 people in the world. And I was like, we need more people to understand this. Because as architects, when you're building these environments, I mean, I was a long time sysadmin, way too long, I have PTSD from it. But sysadmins, architects, people like that need to understand this so that they realize, oh, OK, some of this stuff is not that hard. I can feel a little bit more warm and fuzzy about where I can swap things in and out and feel good and actually get the value out of things I want. So there's places where you might want to swap out the Runtimer or the CRI engine, et cetera, et cetera. But they're not magic, right?  I mean, that's all it is. That's all container images. And the metadata is really, if you think about it this way, it's a way for the human that is building the container images to express to the person that is consuming the container images, hey, here's how I think you should consume this. Here are some sane defaults. Here's the basic command that should run. Like this is a memcached container image, so the command is going to be memcached. Like that makes sense, right? That's pretty obvious. But as container images get more complex, there's other things that the container builder might want to express to the container consumer. And so you really think about this. This is a human interface. This is for humans to communicate with each other using code. And really, if you think about what these containers are, they're a format for collaboration. And the analogy that I talk about is, if you think about hardware, hardware was physical letters, right? I used to get servers from HP or IBM or Dell, and they had to ship them to me, just like a letter. And that was a very slow process of collaboration. Like if I got the server and it had the wrong OS on it or it was not updated to the right level, there was all this stuff where I'd have to call and update the drivers, blah, blah, blah, all these nasty things. And it was very slow and tedious. It was still decent collaboration. It was still more open than we had in mainframe and even Unix days, but it was still slow collaboration. Then kind of the next level I joke is email, right? That was VMs. Email and VMs, they're better. It's not awesome, though, because still you have to go, if I want to collaborate with another human being with a VM image, like the virtual appliances that VM were tried and failed, I have to go pull a 10 gig image from an FTP site or from SCP from somewhere. And whenever I want to collaborate with another human being, I have to mark up changes in that user space, in that VM, change them, save them, and then they have to upload them back to them. That's terrible. That's like email. It's like emailing back and forth LibreOffice documents and using the markup. And if you send it out to five people and each of them make changes, you're now screwed because I can't actually get all five changes. I don't know who made changes first and there might be collisions and all this. But then when you get to containers and you have a format where you can actually define the layers and you can actually see the diffs between the layers, the container image layers. Now we get to a point where the files portion of this and the inputs portion of this are really collaborative. And so we can really collaborate on what the container builder and the container consumer want to do. And so in a nutshell, that's all this is doing. And so there's two basic things, right? There's the config.json, which I mentioned here. And then there is the image layers. And so the image layers get all combined together through a graph driver that basically builds this root file system in that config.json. Then that gets handed off to RunC. And then I show a little bit more complex version of it. So this is the OCI image specification. It defines that you put these things in that container image. The container engine explodes that stuff, does all the work to actually make it into a root file system, builds the full config.json, hands that config.json and root file system off to an OCI compliant runtime, which could be RunC, Catech containers, rail car, G there's a whole bunch of tools that are OCI compliant runtimes. But as was mentioned, RunC is probably 98% of the world is using that. And then that calls the clone syscall, which then talks to the Linux. Typically, Linux operating system could be Windows. Windows has their own syscall layer thing. And then here's the full money shot, as I mentioned. So what are we doing here? There's a container builder. There's a container user. So this is the consumer. This is the builder. And what this person is doing is they're saving a bunch of inputs to kind of communicate, as I mentioned, to the end user. What do I think you should do with this container? And it could be, like I mentioned, a memcache d. And maybe I'm going to set the entry point to memcache d so that this thing always works. And I'm going to set a default username and password for MySQL server, whatever. There's all kinds of things that you can communicate to the end user here. Or maybe you're going to communicate to them that they shouldn't use this without a password. So it should fail out unless you pass an environment variable. Or with Microsoft SQL server, their images won't run unless you agree to the EULA. So you have to put EULA equal Y. So this is a way for the container image builder to basically pass information on to the container consumer in a really collaborative, cool way, which is way better than VMs. And I give some examples. They can use to build a Docker build, Umochi. There's all kinds of tools that are now building OCI compliant images. You can do it with Podman and a Docker file. And then at the end of the day, what gets happened, what happens is you end up with essentially the equivalent of the config on the image side, JSON file, shoved in or registry with a bunch of image layers.  But I show the daemon or the engine, and it really is what I should change this to, because it used to be only daemon, and now it's no more big fat daemon. So I need to change that to really the engine. The engine now has a job. It has to interpolate what's going on in some of these environment variables. Which ones do I want to obey? Which ones don't I want to obey? Which things do I want to add to myself? Like a perfect example is if you don't specify a sec-comp file, the engine has some defaults. If you don't specify a dash dash privilege, the engine has some defaults of what it does with security. In a Red Hat world, S-Fert is used by default. So it will automatically generate an SE Linux context that's dynamic and unique to that container that fires up, and then it will start that process in that context. Those are all defaults that are specified by the engine itself. And then the engine will build the config.json, I mentioned, and essentially the user at that point, though, when they go to interact with the engine, they can override some things.  So even if you're interacting with it at the orchestration layer, you can override some of these environment variables that might be buried in the container image somewhere. But again, it's kind of a way for the person that built it to communicate to the user, hey, here's some defaults, same defaults, but maybe you want to override them because it makes sense. And then again, I already mentioned, it kind of gets handed off to run one of the OCI compliant runtimes off to the kernel and then run. So I'm going to show just a quick example of this, which actually I already have it running. So watch this. So the beauty here is we can docker run bash. We all understand how to do that. cat slash etsy red hat release. It makes perfect sense. We've probably all seen that. But then let's do this with, here it is. Actually, let's just do it by hand. So podman run dash it rel7 bash. Look at that. Same thing, right? Completely command line compatible. Pretty familiar, right? I think most of you would know how to run that. How many of you feel good with that? Pretty easy, right? Now, something I didn't talk about is that now this CLI interface is not covered by a standard. Neither is the Docker API. So there is one gap there, right? Like if you start, I'll tell you, the one place I would recommend not integrating is directly against the Docker socket or against the demon, where you're actually going back and forth in native Docker API. I wouldn't do that because they're completely not protected then. Then that can change and break. We can protect you with a tool like podman for the CLI. And then behind that, we can protect you with the image format, the distribution spec, the CRI interface, the CNI interface. These are, you're pretty safe once you get into that. But there may be a few places where people have integrated directly, natively with the API. That's the one place I'd say steer clear from, doesn't make sense, don't do it. Does that make sense to everyone? So let me show you what I did here. So this is basically what I did, right? It's that simple. I swapped out Docker engine for podman. Pretty much exactly the same, CLI compatible. You won't notice a difference. You're getting the same output. You're getting the same things happening, config.json, root file system getting generated, RunC is running it. Probably 90% the same code, except no demon. And here, I'll give you one other piece that I want to show you is, watch this. So we'll go into another terminal over here, and I'll show you what's going on. So ps3-ac. So here's what's happening. You see, it's actually really easy to track down with podman. SSHDman, my original bash that I was in. I ran podman. Here's that bash. Boom, some things are getting fired off underneath podman. That's so much easier than trying to do with Docker. If you've ever tried to figure this out with Docker, you could strace this and see what syscalls are happening inside the process. You have a lot better understanding of what's going on in the sub-process. With Docker, it's a pain, because you have to strace the running demon, basically mess with the CLI, send some commands to the demon, try to figure out what the demon is firing off. And I've actually ran into this problem where it's actually kind of a nightmare, especially remotely, to figure out what's going on with it. This is a much more elegant interface. This is better for things like another use case that came up last week was the container executor. So they didn't want to use Kubernetes. They wanted to use Yarn. It was a Hadoop environment. They have their own scheduler. They've already built their own jobs. They probably have a ton of investment in that. But they were using the Docker demon to fire off containers. That's an inelegant solution, really, if you think about it. And what was happening is that the Yarn container executor was firing up containers and shutting them down so fast that it was corrupting the Docker demon. Because it's a demon, and it's trying to keep track of all this nasty stuff. And so they were firing up 1,000 containers, shutting them down real quick, and that can end up corrupting the demon. In this scenario, it doesn't happen. This is just cloning and running, essentially, the coolant of a fork and running another process. So there's no client-server interaction.  And then race conditions happen where it tries to send another command to send it shut down. They were running into all kinds of nasty stuff where it would get corrupted. And so we had them try Podman. And so far, they love it. And so this is a perfect example of where they were protected because they used the CLI. They weren't tightly integrated against the API. And everything else below that, all the container images and everything else were protected by the OCI image. So they could fire up the exact same images with the same command line interface, but in a very different scenario with much better results. And those are the kinds of scenarios. People don't care until they do, because usually what happens is you end up in some kind of nasty problem where something breaks like that. And then you're in a deep pickle. And that's where you start to care. So why would you want to do this, right? Well, because I mean, this has already went through pretty well by Dan. But fully community-driven, open-source set of tools, small, nimble core utilities that are standalone, can be used to build, can just be used to run, can be integrated with other schedulers in random ways, like the yarn one. Better security can run as non-route. FIPS is something that we're working on now that we've enabled the possibility of, because our underlying Go Wang is linked against open SSL dynamically so that it can be put into FIPS mode. All kinds of innovations like that. You start to be able to break all this stuff apart. And you can really start to mess with some of the underlying things. And again, you don't realize what you need until you actually start to dig into the use case and actually start to build out real production stuff. And that's when you get burned by having everything buried into a giant POC, where it's hard to make changes to this big ecosystem of things that are all glued together very tightly coupled. And so I would just call it action. Here's some good places to go check some things out. Go check out Cryo, Scopio, Buildup, Podman. I didn't put Podman on here yet, because this is an old slide. And then go check out the upstream work in these libraries, too, because you can kind of see what we're doing and how they're leveraged in these tools. And so I'm actually ahead for once. I guess I flew through that. But I guess I'll break and let you guys have any questions. No questions? I'm surprised. I don't know what you tell me. Question is, can you run Podman as non-rude? The answer is yes. So that's another thing. Actually, that brings up a good point. I'll rant about that for two seconds. So I had a guy beat me up on a mailing list one time about, well, I can run Docker as non-rude. I'm like, no, you can't. Because you're running a CLI as non-rude, but it's still talking to a demon. And essentially, you have complete root access.  You are not preventing anything by doing that. It is an illusion of, it is a difference between the model in your mind and reality.  It is always rude. But I saw a question over here. Oh, sorry. You had a question? And then he had one too. Yes. Thursday's dojo, George Burke has presented Kubernetes in 15 minutes on Santos. He said install Docker in his instructions to get that done. Would it be possible, from speaking as an office, to do that without using Docker? Yeah, you can do it with Cryo very easily. I used to do a demo during this talk where I would actually swap out Cryo live and show how Kubernetes doesn't even care. And actually, we'll keep track of the containers, see that they're not running and restart them in Cryo. Because to it, it's just like pulling that CRI interface looking for are the containers running? They're not up. It'll try and start them again. So it's actually very, very easy. It's one config line change, basically, is what I demoed. And just installing a package, essentially. So let's suppose in our companies or any company, you have a private-owned infrastructure, cloud, hybrid cloud, and whatever you have. So you have deployed these flows in this environment where you have a mix of solution because I feel this more close to private-owned and not to hybrid or cloud models. So this works in every environment or in a combined environment. I think that's the beauty. Is that a question? Yes. I don't quite understand the question. But the idea is, yes. Say Amazon has a registry, perfect example. They have their own registry, right? And if there's no standard, how do I know that I can push my container image into the Amazon registry and then pull it within Amazon? Sometimes you don't want to set up your own registry server. But you want one that's local on that network so that it can fire up quickly. So you have 1,000 container hosts out in Amazon. And you don't want to set up your own registry. You just want to push into theirs. These standards are what protect you that make sure that will work. And that's the beauty. Maybe I just want to run a registry for a few minutes to go cache locally, pull an image, and then blow it out to all these other container hosts locally. That's really nice to be able to do because I can speed up distribution real quick for, say, a batch job that I just want to run. So that's kind of, this is what protects you to do that. Otherwise, you would have to set up your own registry and make sure that it's compatible with everything.  Any other questions? I think we'll drop. So, all right, well, thanks. Thank you so much.


The trade war is over. Just kidding. That is literally what's happened in the overnight Asia-Pacific session. Really volatile session. I'm going to run you through some different graphics and charts, but essentially overnight we've had a situation where it looked like for a brief moment in time that the trade war was in fact over according to the trade adviser Navarro in the US and that caused an immediate spike across assets showing how markets continue to be super sensitive to what's going on with the trade deal. Despite the focus we've had elsewhere on COVID. However, shortly after, I'll talk you through the narrative. Markets have reversed. He said those comments were taken out of context. Trump has tweeted to kind of say as well how he thinks that the trade deal is still on and China will commit to their pledge and so on. So let me just show you the overall sentiment this morning. Before I begin, don't forget to like the video and subscribe to the YouTube channel. Plenty more content coming your way throughout the entire week. But looking at the charts here this morning and as you can see, you've pretty much got these extreme kind of pops reflective across every single different asset class. So in the equity markets here, for example, you can see we've had this extreme kind of V shape where we fell down toward what had been quite a key technical area actually, which was around the low point that we had in yesterday afternoon session, the overnight session as well and then some previous data points going back to the 17th or the 16th and the 18th. This might make a little bit more sense though from a timings point of view. The guys on the squawk, New Squawk did a fantastic job in the overnight. I've gone back through and just kind of gone through and looked at the headlines and when the comments actually came out and the Navarro comment came out roughly at around three minutes past 2 a.m. London time and there was a good couple of minutes there to get on that move before then it started to get kind of circulated and broadcasted across other major newswires and then obviously we saw a pretty spectacular move and somewhat exacerbated of course by the overnight conditions. The liquidity obviously pretty thin at that time of night and you know for anyone who's new to market sitting there thinking well you know could you have gone on that move and I mean the answer is well it depends. It depends if you're really lucky and what I mean by luck is you just happen to be up in the overnight session. Sometimes if you've got various different chart alerts or you've got for me I get the guys on the squawk desk to actually text me but that's because of the relationship I have with them. So if there is something big that happens like that you know if it was super big they would give me a call even in the middle of the night so having some mechanisms like that certainly helps but yeah you definitely had timing on that first one to ride some of that move back down. The Navarro attraction came and the markets were obviously fully engaged at that point because most people were aware of the overnight developments and so you had this extreme pop all the way back to reverse the entire move and then Trump came back with a tweet to basically say that the trade deal is still intact and then we reversed the entire move. So net of the volatility overnight we are pretty much at scratch from where we were before the entire episode of volatility that had been seen. So as you would imagine with that move in equities what did that mean for T-notes? Well T-notes spiked and fell, gold spiked and fell and let me just give you a run through then of some of the headlines and other charts to to kind of summarize the move. Well here here is some of the other movement that we did see the the VIX July futures rose more than 8 percent before then dropping back. If you're looking at this is looking at the orange line is the dollar spot index and then the black line is dollar yen but inverted just so that the two are kind of in sync and you can see here immediate kind of risk-off reflection so flight to quality into the dollar and then completely reversed when the rebuttal came out about the comment taken out of context from Navarro. The Australian currency as well given the close trade ties to China very sensitive to the trade war developments and the Aussie dipped quite sharply overnight but again fully recovered but has been slowly just grinding a little lower as we've gone into the European open. So what exactly happened? Well trade advisor Navarro responded basically to quite a lengthy question on Fox News where he was interviewed and he was asked whether aspects of the trade deal was over and he basically replied saying it's over yes and it took the market I think a little bit of time perhaps you know if you think about the trade advisor Navarro he's not a chief architect of the trade negotiation on going between the US and China that is the trade or the Treasury Secretary Stephen Mnuchin and then the trade secretary Robert Lighthizer they're the two like main guys who are involved in these discussions not Navarro and so perhaps not a lot of people were tuned in at the time and certainly at that time of night and in the US in the evening it takes a little longer for it to gain a bit of traction for it to circulate accordingly then for action to be taken and then it to be reflected on the chart so hence that little latency with the actual kind of move or reaction on that initial phase. Then what happened was basically this Navarro came out he walked back to his statement implying that the trade deal between Trump is over is over he basically said that his comments were taken wildly out of context and this came within the kind of hour or so after he initially delivered that because he'll know full well what the stock market reaction would have been I say the stock market the futures reaction would have been and so he quickly walked that back not forgetting as well this is the same guy when asked about John Bolton's kind of memoirs that he's written quite negatively about the administration and their handling over China he did say he basically blasted Bolton and said that what he's doing is the equivalent of swamp revenge porn so this guy certainly got his way with words in that respect but not only did he walk it back but then Trump came out and he basically tweeted shortly after as well pretty quickly this that the trade deal is fully intact hopefully they'll continue to live up to the terms of the agreement so yeah for me there's really there's really two points I want to make here now just going back to the chart here first point is the way of which the market tends to react to this type of information and what I mean by that is well where is the kind of opportunities when you're trading this type of news driven event and the real opportunity comes with the first first bite if you like if you're not in that one then it can get a little bit tricky now I know what it's like when this type of situation develops in real time because in in hindsight in the rear view mirror it looks like obviously quite easy short but at the time it can be a little bit more nervy than that because he says a comment and you think you know what you heard and you want to get short but actuality the market's not really moving so you're thinking well it's almost like your interpretation is too quick and you're too you're too on the ball for the rest of the market and you kind of second guess it a little bit so you've got to have some pretty strong conviction of just following through on what you thought you heard perhaps then the actual trade entry point for me I mean I'm just looking here on a on a very tight time frame just to kind of give the example of of execution for me the trades opportunity would have come you would have heard that news you would have been a little bit second guessing yourself going why isn't the market reacting this is definitely negative the market then does react it breaks that previous low there which then trades a little heavy and as you can see there's a cluster of price activity that we had at the end of wall street trade this is looking at the s&p future the reopening of electronic trade and and here then that was your opportunity to get short the break and the what we call the classic entry to then play that market back down accordingly so that that for me would have been how to have played it but one of the other things here you can see if I put it back on a 30 minute you see how the market as I said before respected some of these previous lows so whenever you get a fast money move like that you want to be thinking well I need to be booking this trade scaling out of it to ensure then that if the market turns on itself and there is a rebuttal that I'm not going to put myself in harm's way in that respect these trades by definition a very short term and you know whenever you do get that type of move in the Asian session it does tend to be over exaggerated to a certain degree and as I said reflective the fact that there's not a lot of bid and offer in the liquidity in the market at that point in time so here you can see as soon as you got down to around that that kind of pivot level you can see that the fast money traders were just booking some of that profit we go back down to those previous lows and I looked out in the 30 minute chart and then you're out of that trade I definitely would say that at that point you know you'd have your stock trailing pretty tight to then try and avoid this type of situation and you can see from the characteristic of that candlestick when the Navarro retraction came out and he basically said his comment was out of context how fat that green bar is on the upside and that's what you want to try to avoid in this situation you know particularly when it comes to commentary from the Trump administration you know you can almost guarantee then that there's going to be some type of response in that and particularly when there's been a pronounced move in markets in a negative way if you think about it that's definitely what they don't want really to happen they want to talk tough on China but they don't want it to have a meaningful lasting impact so by that point you really want to be out of the market you know these are short-term trades in that respect Trump comes out and obviously you get another little bump higher as he kind of says the trade deal is fully intact and then the whole thing is reversed so for me there's kind of a couple of different phases to the move the one that's most harming is the retraction but the same thing can happen often when you get a news wire source report you know like saying the ECB room or sources say the ECB are going to do X the euro might move really you want to be able to that trade pretty prompt because usually with the processes what happens is Bloomberg source says this the Reuters source says that the market flips on itself so just a couple of words of warning there for anyone new to trading things have steady dough and this is kind of the second point that I wanted to make and if I just I'm going to use this picture just to give me a bit of a backdrop as I discuss it this to me you know when you're coming into the market this morning I don't want you guys to be kind of somewhat influenced by the activity that's happened overnight for me it's really important now that you hit the reset button and it's almost like well if you weren't part of the action overnight then for me this activity these comments given the source is Navarro I think are absolutely redundant I don't think they mean anything there's a couple of things that you will know that are happening at the moment in various pockets of the United States of America COVID-19 cases are rising quite rapidly you know we've seen record levels in the likes of California Florida Arkansas Carolinas you know there's some key areas here where cases are rising very sharply and so this is put out questions then about the impact of the US debate of reopen we obviously saw the news about Apple for example not the Apple stores of the beyond end all that is that you know a sign for example of what could be then a delay in these over optimistic expectations about how quickly the economy can reopen so at the moment Trump is in full assault to try and spin and frame the narrative that this is the the con flu you know this is the Chinese virus as he did in his weekend when he was in Tulsa I think it was in Oklahoma when he was having his first kind of main physical rally again you know so here he really needs to try and pivot away that as these cases get worse which undoubtedly that they will they've probably not quite hit their peak yet in the second phase wave that we're seeing in some states then he knows he's got to start talking this in a certain type of way and so what I feel he's doing here and I would not be surprised at all because tactically I'd probably be thinking the same that Trump and Navarro have probably coordinated this type of scenario where what they're trying to do here is send a little bit of a political message to China as to say look we are willing to end this trade deal completely and and we know that that's not the case but they just want to put that out there on the table and soon as the markets react like they do it's kind of like well no actually that's not what I said that's out of context and then Trump comes out very quickly suspiciously quickly and then tweets yeah actually the trade deal is still on but that they've already achieved their objective there markets have recovered we're flat now from where we were but that warning sign that gun has been put on the table now as far as the the US tactical approach politically is concerned so yeah for me this is all just politics you know Trump also following it up as well saying that a second stimulus checks for Americans are going to be coming for the COVID-19 aid package details are coming in a few weeks so it's a full on assault at the moment as far as Trump is concerned it's a Chinese virus we can end the trade war but actually no the trade war is going ahead the agreement is in place and actually American citizens don't worry if you are losing confidence I'm going to swing you another stimulus check your way it's all gravy at the moment so yeah it I don't think you should get too spooked by what's happened perhaps I will end up being wrong but I don't really think it's a big deal quite frankly despite the severity of the the volatility that was seen in the overnight session of course so yeah that's my my take the other thing here as well that as a proxy and I've mentioned this a couple times before but it's always interesting how correlated it is to these these kind of bumps if you like in negotiations between US and China and that is that North Korean provocations raise fears of military escalation where Kim Jong-un is using threats against Seoul to reset negotiations with the US according to analysts are warning you know this is the sort of thing where again Trump doesn't want to look weak in his control in other geographic regions around the world as well remember he was the one who was really pumping it that he had brokered a historical peace agreement only what probably less than two years ago when the North and South literally crossed over the the DMZ line and to shake hands for the first time with Trump being the main instigator of getting that that deal done and now any any the way that China tends to respond here geopolitically is by unsettling the Korean Peninsula now we know that there's no direct obvious communication but we know the strategic alliance that these two countries have so if Korea North Korea starts making sounds against the US allied country which is Seoul in South Korea that makes Trump look a little weak in his control and what otherwise was quite a key kind of you know badge of honor if you like of his administration and what he had achieved in that peace agreement so all of these things are definitely connected in a geopolitical sense and that's what I think this is this is purely just a strategical or strategic moves on on the political side so for an intraday trading basis what I want is for you guys to kind of almost come to the notion that look if we're all square again now the only one final thing I would say is that what you can evidently see is that markets do remain very sensitive to trade war news you know headlined reaction to a certain type of trade war comment from a certain type of individual can have to propensity to move the market quite sharply as you've seen so hence the reason why you always need to be kind of semi-engaged listening to the squawk keeping an eye on Twitter and a news feed just in case but hopefully my explanation about the execution side you know it was a little bit over pronounced because of the overnight session but there's definitely a method to how to trade that type of kind of headline driven event all right a few other things I just want to cover off and then I'll wrap things up this is talking about the UK and what we have here is Boris Johnson today reject or will reject misgivings for some leading scientists and press ahead of with a plan and will basically push ahead with a plan to cut England's two meter social distancing rule he'll also add cinemas and galleries and museums to list the premises able to reopen on the 4th of July pubs restaurants hotels hairdressers will also be given approval to reopen their doors with coronavirus precautions on the 4th of July this comes the day after the death toll from the virus in the UK had risen by just 1515 that is the lowest in fact since mid-march so yeah definitely Boris in a similar situation of course to what we've seen other areas like the United States of America where these politicians who are in charge are definitely under pressure to kick start the economy again and part of that would be helped along by a reduction of the social distancing rules to what I think they're calling the one meter plus rule rather than two allowing then some of these other types of sectors to reopen to some degree of normality and obviously that means people get back to work and the economy can start somewhat functioning again whether or not though that comes at risks of course of a secondary virus that's the tail risk that we'll be monitoring the other thing is this and I'm covering it really more again for anyone who is relatively new to monitoring this type of information so basically Iran backed Houthis have been well Saudi has intercepted ballistic missile headed to Riyadh from Yemen now one of the things here is that that sounds like a quite a punchy headline you know you would see that you'd think hang about what there's a neighboring country where there's Houthi Iran backed militants firing ballistic missiles on capital city of Saudi Arabia that sounds quite worrying the problem is here is that this happens frequently the Iran backed Houthis have been fighting Saudi led military coalition since basically 2015 it's about the last well over five years now they have repeatedly claimed responsibility for attacks on targets in Saudi Arabia they try to also disrupt the aramco network particularly in the infrastructure basins south of Saudi Arabia and this is all part of the kind of ongoing proxy war that is then the underlying tension between Saudi Arabia and Iran in the Persian Gulf so yeah I just wanted to really stress that you know you see a headline like this context is definitely important because as you've seen in oil it's not interested and quite rightly so you know as as nasty as this headline might sound it's not a market mover because this is this is actually the normal status quo what did move the market overnight was a momentary blip on the Navarro comment but obviously that's been reversed like every other asset has all right a few other things to look out for for today there are some meaningful data points coming out momentarily this morning so I'm just wrapping this up it's just coming up to half 7 a.m. this morning now but as we go through 8 15 8 39 we're going to get the French the German and the Eurozone manufacturing and service PMIs and these are indeed the flash numbers the UK numbers will also come out at 9 30 so all of these are important the PMIs always are they're forward-looking so it does give us a little bit of a kind of a barometer of how confident people are about the the future one thing I would say is that most of these data points are going to reflect quite sharp bounces from their previous numbers but I think I mentioned this in my my macro menu I issued on Sunday my kind of look ahead I wouldn't read too much into that and and the point being here is that you're coming from a very low base you know the PMI has got absolutely decimated as a reading during the the midst of the lockdown so as we start to reopen albeit in phased and gradual approach then we are expecting this kind of almost v-shaped movement that we've seen with payrolls that we've seen with retail sales the PMI should follow suit the problem that we have is that when you start looking at some of the underlying activity in the economy on in the real terms rather than these soft sentiment-based indicators is that the economy still is quite far away from functioning anything like it was pre-covid-19 so if we go back to sort of January February time so this is a diffusion index it basically means is how confident are people either are or they aren't and to what degree then we'll dictate whether this figure is over 50 and expansionary or below 50 and contractionary so yeah confidence is going up does not necessarily mean that confidence can't come back down all the time before then reality actually takes place so yeah when it moves the market I mean if we get a spectacularly strong number sure it might but what I'm saying is that it might be a fairly short lived response because I think other people will be looking at a similar way that I've been explaining otherwise going into the afternoon you get the US equivalent from market the data provider otherwise it's relatively quiet in the US session you've got the new home sales data you get the weekly oil infantry numbers coming out the API there is a Chinese Russian Indian foreign ministers meeting happening no set time today but just given the context of what's just happened with some of these US related comments you know the relationships being forged between China and Russia is always quite interesting so maybe worth keeping the air out for that and in Bank of England Governor Bailey is speaking at an event women in finance event at 945 this morning and that's it so yeah any questions feel free to leave me a comment on the video absolutely happy to to engage and help if I can hopefully you found that session useful PMIs this morning definitely warrant monitoring quite closely but with that I wish you guys a good day ahead thanks for listening