Okay. Welcome, everyone. Good morning. We're going to start the presentation now. So we're here to talk about OpenStack Feed Management. It's a very new project called Creton. So we're hoping to introduce it to the community and also get some feedback. So I am Solochon. I'm a software developer at Rackspace. Interested in OpenStack automation, serverless technologies, et cetera. So if you guys are interested in any of those, feel free to reach out to me, IRC, Twitter, all the usual stuff. What we're going to talk about today in this presentation is we're going to introduce the Creton project to the community. We're going to give a little bit of background on what we have in terms of experience from our public cloud, how we use something similar to Creton project in our public cloud, and how we draw upon that experience into this project. We're going to discuss the project architecture, a little bit more technical detail. We're going to do a little bit of deep diving into that, and then we're going to do a Q&A at the end. So why this project? What are we trying to solve here? There was a user survey published by the OpenStack UX user experience team, and one of the points highlighted in that survey was that maintaining consistency and minimizing complexities are the primary challenge confronted by the OpenStack community right now. What does that really mean for us? For operators in particular, what does that mean? It is a problem of how we should minimize complexity for operators in a way that they find it easy to run their OpenStack fleet, and that's what we're trying to solve here. How can we make it easy for you, for us, so that we can have a very easy way to run an OpenStack, maintain it, how do we manage all the different moving parts within the OpenStack fleet, and how can you make it easy to do that? In that, we have different state, different things. We find that maintaining inventory, for example, is a very sort of like a pertinent point to discuss within the project. How do we do that? We can have flat files maintaining inventory. People have different ways of doing this. We have GitHub, like you can put it in GitHub, you have files, but there is no consistent way of doing this within the community right now. How do we handle metadata? It doesn't have to be metadata within the service, but it's a fleet metadata. How do we handle fleet metadata so that it's easier for operators to sort of call on that to do whatever we do downstream to automate our fleet or to manage our fleet? That's one of the other points. Moving away from metadata and inventory a little bit, how do we make it easy? How can we make the environment a self-healing environment? I think that's a very powerful sort of like a point to have within the operators circle as to how can we not only do, how can we minimize the repetitive tasks? How can we make sure that we can automate some of them so that something happens next time we know there is a very standard way of handling that? We can draw up on that to maybe log it, maybe have some other processes, call upon that to give you more information about what was done, something like that. By doing that, we also make sure that we provide a secure and consistent way of doing that repeatedly, and that's very important as well. We might have processes where each of us does it differently. We solve one particular process, I do it one way, he might do it something like a different way, and it's in our heads. It's not on a process or workflow, and that's what we're trying to solve here as well. And last but not least, how do we, I know everyone has monitoring set up, everyone does their monitoring, feeds that back and say, hey, okay, something alerted, something is broken, how do we fix that, but how do we step out of that and say before it's broken, or before I get an alert, can I audit it? Is there a way that I can know what's happening within my environment and then take actions based upon that? Maybe feed that into some other analytics tools and then have some sort of decision making power on what's happening within the environment, and can we do something like that? And those are the problems that we're trying to solve here. And before we come to the creation project itself, we in Rack Space Public Cloud have been doing this for a little bit of time now, and we're going to draw up on that experience, talk about that a little bit to give us a picture of what happened within Rack Space Public Cloud that we did something like we take these steps that we had a tool to automate things, to have audits done, how we sort of like gathered all the monitoring data into one. So we're going to talk about that a little bit. So I think everyone will agree that when you have like a very small cloud with a public cloud or private cloud, it's easier to sort of like not need automation, right? It's easy to just say, hey, I'm going to put my stuff in files because I only have like one cell or one region, have 20 servers. It's easier to maintain that. And it's easier for your ops or easier for your DevOps to actually work to that because it's only like one small region or one small cell. But what happens when that grows into 50 cells or five regions, when you have 50,000 boxes or when you have 200 boxes, right? It's not feasible to just work from fat files or just to keep committing stuff into Git because all the times, as you can see, servers are not always green. You have failures. How do we make sure that we're tracking this all the time? I know we have alerts. I know we have monitoring. But how do we make sure that these alarms, these alerts and monitoring is presented in a way that it's consistent, whether it's five servers or 500 servers, right? That you didn't need to change your processes in order to tackle five versus 500. And this is what we found in Rackspace as well. So when I started, long time back when we just started OpenStack Cloud, the first maybe couple of months was fine because we had like maybe one region of a few hundred boxes. As that grew into multiple regions, many, many boxes of servers, it became hard to just operate on that, no matter how big the team, right? So we had to have a process where we sort of drew out all those alerts into one. We were using Nagios. I'm sure everyone here knows Nagios is not very good with clustering. So we also was looking at when we're doing it, when we're trying to remediate some alerts, we're making sure we're going into each Nagios page, making sure what's happening. You got emails, but then emails were per person, right? There was no central place to say, hey, this is what happened. And everyone had the same view. If I got an alert email, and if you got an alert email, there was no coordination between someone else and myself to say, hey, this is who is working on it. So the only way to do it was to aggregate those alerts into one place. And what that really looked like was something like this. And what it basically did was it aggregated all the alerts into one. It told us, hey, we have these many servers or these many regions or cells. And I'm having this many alerts, whether it's warning or critical alerts. And as you can see, some of them are in red. Some are just zeros and some are warning alerts. And this was good. This was good for the first couple of months when the infrastructure was, I don't know, let's say 1,000 boxes, right? But what happened when it was 50,000 boxes, for example, is that it became almost impossible to manage that even. Because there was too many alerts, too many alerts coming in, too many failures, just to manage that dynamically to make sure, for example, take an example of doing a code deploy. When you do a code deploy, you want to make sure that the broken boxes do not break your deploy, right? So you want to have a dynamic way of filtering this out during the deploy process such that a new code deploy doesn't get stuck on a broken box. How do you achieve that? So we had to figure out a way to sort of automate the process where, first, before we get to the alert, let's find a way that we automate the process of fixing a broken service, a broken box. So the previous UI that was aggregating the alerts now had a secondary service where it forwarded all the alerts. And that service automatically tried to remediate these alerts, these alarms, to try to fix the box. And it only came to an operations sort of like few when the automation process failed. And that was a huge win. That got us, that was eliminating a lot of these repetitive alerts where you would see like a broken service. The process was pretty straightforward. You would go in, find out what's wrong. Let's give an example. Let's say a computer service was down, right? The usual process of handling this, if I'm an ops, is I would log into the box, see what's wrong with the service, try to start it, look at the logs, see if there was any exceptions, see if there was any errors, make a note of that, and then try to start it again if it starts all good. I'm sure this is how we do it normally within the operations circle, right? But it's the same for you. It's the same for me. It's the same for some other one, someone else, right? We all follow the very, we all follow, maybe slightly different, but we all follow the same pattern. So if we can automate this, we have a very steady way of saying every time this happens, make sure we do these things. Make sure we follow these steps. Put it in a center place somewhere. Make sure we're not in a cycle or we're not in a loop where we keep starting a service. So we make sure we exit it if the alert was like more than five times a day or more than a few times an hour or something. So it had all these logic built into the service to say, hey, okay, if something happened, try to do this. If it happened more than this time, exit alert escalated to a person. If not, if we can fix it, awesome. And this is what we did. And that got us quite far until we hit the problem that I mentioned before where we're doing a deploy and a broken box was causing us problem. So how do we fix that? The only way to fix that is to have some audit mechanism in place that goes around, checks, let's say if a host is up or not, and then notifies some central place saying, hey, this host is broken, we need to do a deploy, skip it. In order to do that, we needed a couple of things. One, we needed some audit service in place. And two, we needed a central place where we can go back to say, hey, this box is broken, so make sure it's not, it skipped during a deploy process. And this is what we're trying to show here. We have an auditor in place that goes in, audits various things, whether it's services, whether it's just about a broken box, whether it's some security role, whatever you have, it's sort of like a workflow that it goes through, audits, and then comes back to say, hey, this is good, put it in some central place, happy face, no, you need to fix it. Put a workflow in place, sort of like an alarm in place for the resolving service, and that will go in and try to resolve. If it failed, escalate. Here's a quick example of something that I'm talking about. For example, here, there's a task called deploy catch up, and what it would try to do was if you had a code version pushed out to your fleet, and a couple of boxes missed that, for whatever reason, the boxes were down at that time, and we skipped it. Make sure the next time the audit process runs, we catch the fact that these code versions were different from what we should have, and then go back and create a task that said, go back, make sure that the code version is right again. And it's, as you can see, it's created by the auditory process here. And the same logic for fixing or remediating alerts can be applied to doing workflows. What does that mean? For example, you have a scenario where you have, you need to migrate a box or migrate customers, migrate version machines from one server to another server. You can do that by hand. You can say, you know, follow a certain steps in order to do that, or you can completely automate it. You can, for example, in this one, you can see there's a workflow process in place that says, when I have a process where I need to vacate a node, for example, disable the compute, disable the compute service, make sure you migrate, there's some pre-migration checks done, make sure you disable monitoring, put that data back into some central sort of repository where we're tracking all this stuff, and so on and so forth. As you can see, it does a whole bunch of different things. It might go through, it might fail. In this case, I'm just showing something that failed. If it fails, it's fine. Just let the operations know that something failed. If it went through, then fine. In this case, what we're doing is we're migrating everything out of a box, killing that box, re-bootstrapping it. Maybe you want to put a fresh code into it. Maybe you want to do a fresh install of the operating system. You do all that stuff, make sure everything looks good, passes the QA, all automated, and then you put it back into production. So this is the type of stuff that we did within Rackspace Public Cloud and we're doing with Project Cretone. And it's worth pointing out that this process, this workflow that you just saw there, we're able to go and scale that out currently in Rackspace Public Cloud to running with tens of thousands of physical nodes, doing things like that exact workflow. You want to pull that back. Can you bring back the previous slide? Previous, previous. There we go. This exact workflow we would use to go and say we need to go and upgrade our hypervisor because we have an embargoed patch. And this weekend, we need to go and get that patch onto every single machine, make sure that we have the mitigation in place so that by the time the embargo is over, we're all set. And this used to be an expensive time-consuming process in terms of manual labor. And now we have it something that's basically completely automated unless there are some failures on a given box. There are always failures at thousands of nodes scale, but most of them go through. Absolutely. I mean, think of it like this. If you had to do this on a thousand box and you were one person doing this, it would be pretty much impossible to track thousand boxes at the same time, right? But having a process that tracks it for you and only notifies you when there is something wrong is a much nicer way to handle it than having to track thousand boxes on command line or through UI, whatever it is. So this is what we sort of draw experience upon to bring it into the project. Jim is going to talk a little bit more about sort of like the technical deep dive into Crayton and give us a little bit more info on that. Thank you. So sure. I'm Jim Baker and I work on Rackspace Private Cloud, also part of the OpenStack Innovation Center and a variety of interests and here are some opportunities to contact me if you're interested. So looking back post-mortem, you might say, what do we do right? We did a lot of things right, right? I mean, I think that we were able to, we have an internal asset management system at Rackspace, Rackspace Core that we've been able to augment with some inventory that the existing fleet management was able to utilize. We're able to go and systematically make changes to that environment and also determine what is actually going on. So if there was some conflict between what asset management knew or did not have enough information about, we could audit that. We're using Ansible playbooks to do the actual configuration, which meant that we were able to build on something that worked well.  Why couldn't you just use what we use in Rackspace public cloud today? Why can't we just use it in Rackspace private cloud today? Well, in part, the inventory is tightly coupled to our asset management. There isn't something that says, here's a freestanding inventory system that can work with other sources of truth. The playbooks were very much tied with how we manage Rackspace public cloud. And it was a multi-tenant. And maybe not everyone here wants to manage multiple clouds, but it is a use case for some. So let me introduce Kraton. So the first thing is that we're really big fans of trying to find what are the best and current OpenStack practices for developing OpenStack projects. So that means using the great infrastructure out there. I can highlight, I shouldn't point a laser on Josh right now. He's sitting in the front seat for those watching on video, but we're able to, let's see here, there we go, we're able to take advantage of tooling like Task Low, for example. We're utilizing SQL Alchemy. We're utilizing new functionality that's available in MySQL and Postgres, namely support for JSON columns. Another goal of ours was to simplify the underlying, make it really, I mean, I don't know, it was fairly simple, but we really have come up with, I think, a fairly simple Python object model for going and working with all of our internal representations that is then backed by SQL Alchemy. One thing that's of note here for those who are in the development side, oops, can I just do something? There we go. We use synchronous coding, where possible, because if we do things like hand off asynchronous work to say Taskflow to work in worker pools, then if we're going and otherwise modifying representations of objects with our REST API, if we do that synchronously compared to using, say, EventLit and all the issues that come up with that, far simpler code, just saying. Another thing that I think we've done here that's pretty nice is that we are using a map-reduced paradigm based on, again, Taskflow and how we can basically construct a TaskGraph that has things running independently. And most importantly, this is a second system. We've already implemented something that works, right? So the usual thing here is to just go and say, well, wouldn't it be nice to add this and add that and so on and so forth? And what we really try to do is keep it as simple as possible, really come up with a set of core concepts that we can then build an ecosystem around. More importantly, what all of us here, if you're interested in working with us as a community, could build an ecosystem around. So I'll highlight one user story just to kind of give you an idea of what we're looking at. So we were given this by some people who were looking at, you know, what is really necessary to make operational work with OpenStack much better. And so we have this as a cloud operator, I need to check my deployed physical resources against a set of policies and rules so they can meet security, availability and other requirements. Obviously, this is something that we need to be able to do. And yet at the same time, it can be really challenging to go and keep one of these user stories always up to date, consistent in terms of actually achieving this as a cloud operator. So I'll highlight here policies and rules. Well, what types of policies and rules? Where is this coming from? Well, one selection might be, I'm utilizing, say, OpenStack Ansible and the security role that's available with OSA. It might be something else. Okay. Some playbook, some chef recipe, some puppet book of some kind. I forget what it's called in puppet, sorry. But something along those lines, right? And if I'm going and continuing the OSA theme here, I need to be able to configure it with variables according to the policy I need in place. The OSA security role, for example, is pretty, has a lot of configuration options for reason. And I want to be able to go and apply that playbook against my inventory. So what does that mean? Well, I'm going to be maintaining, I need to maintain my inventory host, right? And I don't want to do that in some flat file, even if it's version controlled or anything like that. I want to be able to go and maintain that ideally in a database. And I also want to be able to capture the administrative aspects. How are these devices actually being managed in terms of layout, in terms of regions and cells and things like that? Lastly, we have to consider the operational aspects. This thing needs to scale out, all right? And we need to, again, consider multi-tenancy. So I'm just saying that unpacking this one user story, which seems pretty simple, gives us a lot of input in terms of what this Creton project should be about. It's very much aligned with what we had previously done in public cloud, but it also gave us some insight into what we should be doing next. So just as a sort of quick overview of what we're building here with Creton, this is our logical architecture. We have a, I think, a fairly straightforward core set of services here that we're building out. Not all of this is, we are still very much a work-in-progress product. But we have here an overlying Python object model connecting together inventory through SQL Alchemy that's actually doing the modeling. You could plug in your own modeling, but we're not trying to build every possible plug-in here. We're just trying to go and show at least that one back end would work. And we're also going and utilizing Taskflow and this job board to actually do our audit and remediations. And as much as possible, support a variety of different ways of accessing the same underlying REST API, including a command line client and a Python client. I should also mention that this code base in terms of the core is all Python 3. The Python client is 2.7 or higher. So for those who are interested in working on Python 3 without having to go and deal with packed ports and six and things like that, not that that's difficult, but it's just more extra engineering work. We think Python 3 is the way to go. Next idea. The fundamental thing that you're working with in terms of your inventory of what you need to manage in your cloud is some device. It's a host. It's a top of rack switch. It's a container for your management plane. Devices are key to what we're building out. We take devices and go from there to building out a specific your cloud. Okay. Devices also have relationships. There's containment. So a host is part of the cabinet. A host can contain those containers for the management plane, which is that what we use, for example, with OpenStack Ansible. There's also the network topology. How do we go and link up at the cabinet level through interfaces to our network?  So I can say that the reason I have this node is to go, this node's purpose is to be a compute node. This node's purpose is to be a storage node with Swift, so on and so forth. All right. Sillow was talking about earlier, managing configuration is a really hard problem, as we all know. Okay. So who here loves going and managing DoverConf? Oh, yeah. So we got one person here who's just like, yeah, that's not true. So it's like, how many config settings do you have to go and manage in your cloud? Well, as you multiply that out, as you build your cloud out, it just becomes more and more and more, right? At some point, you're building this out in a database. Rackspace public cloud, we're using MongoDB in conjunction with the Rackspace core asset management system. You might be using a database system or you might, because you're running a smaller cloud, be using a lot of text files, but regardless, you've got a whole management headache in front of you. All right. And even if you are using scripts to try to template this and whatnot, and again, I look at something like OpenStack Ansible in terms of how it manages things, it becomes very difficult to manage over time. In part, where is the traceability on that, right? Oops. How do you know that this configuration setting, where did it come from? It's really hard to know what's going on, especially over time. So what we've built out here is a fairly flexible variable system. We wanted to make it feasible for, we know that we couldn't figure out every inventory configuration setting in advance in our schema. That would have been possible, right? There's such a variety of things. And of course, we also understand that if you look at existing configuration management tools like Ansible again, they have a fairly nice variables model to make that a little bit simpler. What we've done is taken that and basically built it out, put it, I guess, a little bit on steroids, you might say, such that it becomes almost like what you see in a directory management system, including the ability to specify things at a top level and have them percolate all the way down, but with the opportunity to override. We also allow variables to work on most entities. And I'll just show one example of this because I think it's interesting to look at the underlying code just to see how simple it can be from a user perspective. So we have here for our variable support, we have a simple to use mixing class. It should work well with caching. We haven't really tried it that way because you don't optimize unless you're actually seeing the need to do that optimization, but let's just say that it should. And it allows us to readily identify what happened. Where did this setting come from? Who made that setting? As we build out our back, what was the whole workflow associated with making that change? Very important with a large cloud to understand changes over time. I'll just highlight this one piece of code here in case you're interested. So we take advantage of, as I mentioned, Python 3 has this really nice thing called chain map, which allows you to go and implement scoping logic for variables similar to what you see in Python's local versus global scope resolution. Here we're using it to just say, and I'm ignoring whether or not you have cells or not, I'm able to say, all right, in my device tree, resolve all my ancestors and make that part of a chain.  So if I want to configure it at the highest level, the region, I can just do it there and you can see it's just one more line in the underlying Python object model. So very simple code. And I just bring this up as an example of this is a project if you're interested in working on as a potential craton developer. Does that look that bad? No, okay. So we're really trying to go and make it as simple as possible. And I have to say there's a little bit of logic necessary to make that actually all work. So it's all beautiful and it's looks like, you know, just a standard dictionary. But when we do that, then from a usability perspective in terms of someone who's consuming that as a developer, it becomes much easier to work with. Okay. And now we have a screencast. Yeah. Next slide. Yeah, I'll let you. Um, the screencast is basically what it's doing is it's showing what Jim just talked about, as in what this variable looks like.  So if you're managing Nova Conf and you want to see what what it actually means to manage that through craton, right? And this is sort of like an a see if I can play it first. So you should be able to one time it doesn't work. And we actually prepared the screencast so that the demo would just work. Yeah. Are you not able to move the mouse? Maybe it's just not on the screen for some reason. Oh, yeah, there you go. Here we go. This is great. Yeah. Okay, so what we see here is basically a query I can before there's a way to I want to pause that. Sorry. So if there's a way to so before we start, I want to say we have a craton client in progress. The reason we're not using it is it's not usable yet in some of the things that we're trying to show, which is why it's not there. But we do have a client. So what we see is the rest API at this point because that is the one standard that we're all working against. Yeah. So what we see here is basically a rest API call to the service to say give me all the regions that I have configured in my in my craton service, right? When we make that call, you will we will be given a list of your regions without too much metadata at this point. And one thing to notice is when you call upon the regions, a specific region, it gives you a little bit more sort of like a data on on that region. I'm going to pause it here just to highlight a few things. For example, for example, if you can see that when you call upon the region, it's giving you not only some information about the regions, but it's the fact that we've prepopulated this with some metadata, some variable information. For example, you can see that quota RAM has been set. Similarly, there's something called NovaCon for one and NovaCon for two with some random values. Now, if I go ahead and set a different value for that, you can see that that value has now changed to whatever we set it to. But this has been done on a region level. So when you're setting up your config variables, the way you want to do it is you have all the common configuration that applies to the whole of your regions set at a regional level. And when you pull that down, your hosts need to be able to get that info as well. And as you can see here, when I query on, I'm about to query on a host saying, hey, give me information about a specific host. The variables that I set at the regional level should resolve to that host level. And what that really means is if you were managing configs per host level, let's say you had many different configs that you were maintaining on a particular host, you could do this to say, every time I query upon this host, give me a set of configs that's true for this host only. And that's a big flexibility over having to manage this manually. And that's what we're trying to show you. And obviously, you can override like we're showing here. NovaConferred2, if you override it on a host level, it stays. So when you're managing configs like this, it becomes a very easy way to make sure that you have everything common set on a region level. You can do the same on a cell level. This is purely on the compute part of things. And you can resolve it down to host levels. And it's not just one configuration value, but you can do the same for many different types of variables that you would usually track on a host level. So eventually what we plan on doing with this is going and extending this to an inventory fabric. Being able to chain information like what we've done here, not only extends to going and saying it can come from administrative things like configuring at the top level or my given region or possibly project or whatnot. It also allows us to bring other information, say from Nova or sender, about that same device. So we can link in this information together. Pretty straightforward. Chainmap enables chaining. Great. That's exactly what you would expect. So we're running a little bit of time so I just wanted to go and quickly get into the other really important piece here which is our support for workflows. As we saw with the workflows that we used in Rackspace Public Hub today, the ability to run some sequence of tasks with these assumptions really gives you a lot of power. So if your individual tasks are convergent on some desired state, thereby allowing retry. And those workflows themselves are also convergent. You can just keep on running them again and again, assuming your configuration hasn't changed, they'll converge on, again, that state. And those tasks themselves are independent of each other on different devices. Then you can really map this out in a true map-reduced architecture. One nice thing about a map-reduced architecture is it means that you can go and distinguish the actions that you're doing. I'm applying these tasks to make some change in desired state on this given host such as to go and migrate all of its VMs to some other host. It can be run independent of considerations about, well, what is the data center layout? Which is great because now I can go and think about the scheduling that should be responsive to that data center layout. Be data center aware. And if you look at what we do with Rackspace Public Cloud today, exactly what we do. So we're not going and just trying to migrate all hosts off of all cabinets at the same time or some random subset of it. But instead, we're systematically doing that work. And so we can use this map-reduced architecture. We can map this workflow to some device. And we're able to take advantage of Taskflow's job support to actually go and run the desired multi-level TaskScraft that corresponds to this. We can probably skip this. So do you want to go and do the- We probably skip this because we're running out of time. Yeah, I think we're out of time on this. So let's just, so just in general, if you're interested in what you saw here about Cretan, here are some contact information. And at this point, if we have any questions, if we have any time for questions, please address us. Thank you. I don't know if we have time for questions. Is this on? Yeah. If you do, I have a question. So it seems like the work- No one's kicking us off yet, so. Okay, good. Seems like the most interesting part of this is the workflows. Can you talk a little bit about how those are actually executed and how you scale them? Do you have to run an agent on each of the boxes that you're managing? How does that work? It's, that was the big question that jumped out of me from this. Sure, sure. So we can talk about what we do in public cloud today and- Yeah, so the process right now is to, is what we were using Celery as sort of like the backend to execute all the Python processes. Everything is sort of like encapsulated as a plugin. So you execute a plugin. Currently, we're looking at Taskflow. And we can probably expand upon that. And we're also looking at sort of like sandboxing every plugin within a container. So everything runs inside a container to make sure that it's sandboxed. So we're looking at that as well. But it's within the Taskflow sort of like environment. Right, and so this is different from running containers on those hosts. It's actually running containers on workers. So that we can go and ensure that the workers have all the necessary environment, including any associated software installed to do changes on the target devices. Hello, I work on Kameleon Cloud, which is a test bed for computer science that was built using OpenStack. And for us, what was really important is to be able to do an inventory, not just of how many computer nodes we had, but of all the devices inside those computer nodes, the amount of RAM, the number of disks, the revision number, BIOS and firmware, version numbers and so on. Is that something that Crayton supports? In a way, yes. So what we're looking to do is have audits that would go in and sort of like read all these data out and put it in the inventory for you, right? So if you were running these audits in a cycle, you would always have, there needs to be some sort of synchronization between what's happening in your environment and let's say with your asset management system and Crayton, right? So Crayton being sort of like the front-end service for all your fleet, you would wanna make sure that we're syncing that all the time. So we have a workflow, sort of like audit workflow in place where we're reading these values and populating the Crayton inventory service so that when the downstream services that consume Crayton want to know about them, you can always talk to it. You have sort of like a central one place to go to ask questions about what do I have in my environment. So having this extensible inventory that you can go and one, attach variables to say arbitrary devices, arbitrary variables to arbitrary devices gives you a lot of flexibility along the lines you're describing and two, having the opportunity to not only do that in say a script that's updating things from other sources of truth but is actually utilizing the workflow system itself, collect that information, gives you a lot of power to go and augment what you know about your environment. Okay, thank you. And just a quick another question. Are you planning to interface with Aronic Inspector to gather the data that's produced by these two? Yeah, we are. We're looking at, so there's, even within the OpenStack ecosystem, there's so many different like watcher projects, for example, right? There's a whole bunch of different projects in place right now that will do a whole bunch of different things that we would probably consume. So we will work together with, for example, with Water to get data back from that or maybe it's someone ask a service that's running. You'd have to feed some downstream analytics service as well. So eventually I think we'll do all of that, yes. Thanks a lot. All right, I think we're good. Thanks very much. Yep. Sorry guys.


So this video is a guide for people struggling to progress, struggling due to a lack of loot, struggling due to enemies being too tough and this is resulting in progress being halted and that will tear bar either not moving or going down. Today guys I will explain everything you need to know and understand about how enemy levels and loot works in this game and what you need to do to be able to compete if you are struggling. How's it going guys, my name's dpj and if you enjoyed the video leaving a like really helps out and if you like what you see and want to see more outriders on a daily basis be sure to subscribe and turn notifications on. So after streaming last night even after posting a few guides to help people there are still folks out there that seem to be struggling and cannot progress yet they just want to play the game have fun and get to that end game but can't because they are stuck. Now I have been there already within my first couple of streams I was making the very same mistakes people are doing right now and they are easy to do so this guide is for those people out there who want to play the game as I am looting, shooting and going up world tiers as soon as they are unlocked. If you are like the few I have seen just bumping through the campaign on a world tier one this guide is definitely not for you.  With each world tier enemies are scaled up from a world tier 5 to 15 enemies gain extra levels over you a world tier 5 enemies have two extra levels on your current level on a world tier 6 enemies have three levels on your current level on a world tier 7 enemies are four levels above you and enemies on a world tier 8 where I am right now enemies are five levels above you what this means is your character class level which you can see within your inventory screen at the top left no matter what level that is the enemy will always have those plus levels on you depending on that world tier you're on so if like me you're playing on a world tier 8 you're a level 21 enemies will be a level 26 it's as simple as that. Right now as I make this video I'm a world tier 8 which gives the enemies five extra levels on me this means enemies I will encounter will be a level 26 because my level right now is a level 21 it's also important to note if you are within a middle of a world tier for instance me right now I'm about halfway through a world tier 8 if my character level goes up from a level 21 to a level 22 so does the level of the enemies they gain that extra plus level also now with enemies being at that extra level what can be done for you to compete with them well it's quite simple here you need to earn loot and this is also super important to remember loot scales exactly the same as the enemies and I mean exactly the same so playing on a world tier 8 loot will drop at a max of five plus levels over your character level so if your character level like mine is a level 21 loot on a world tier 8 will drop no higher and max out at a level 26 and this will happen until you either level up your character again or go up another world tier progress on and this is what people need to understand if you are playing and fighting against adds that are three four five levels above you you need to have armor and weapons at that matching level to be efficient and compete I reached a world tier 8 yesterday and understood this concept instantly and even though my armor was maxed out for that world tier 7 progressing until a world tier 8 although enemies only went up by one single level it was easily twice as hard so what I did is what I recommend you guys do if your gear levels are not that at the same at the enemies you are facing because that's the important note all your weapons and armor should be the same level of the enemy you are fighting if the enemy is a level 15 so should all your weapons and armor if the enemy is a level 25 so should all your weapons and armor so the next question is no doubt how do I earn armor at that level when enemies are just too hard to kill and I ain't getting anywhere well this is quite simple too use one of my chest farms to get that easy loot which will drop at that level you need it to be the chest farm I will stay needs to be done at the highest world tier you have unlocked by the way and what it does is see you gain around eight chests in little over three minutes each chest drop in loot and having a chance to help you progress so the chest farm you're seeing in the background now it is within eagle peaks so from the lobby select the story points go to eagle peaks and then select the very bottom mission of speak to Jacob once you load in run to this flag and travel to this fast travel point of bonka peak once yeah follow the route I take on screen now if you haven't gotten to bonka peak yet you can use the original og chest farm from the demo which by the way I will link both these guides on these chest farms within the video description these chest farms you will grab all of the chests quick to the lobby then start the process of selecting the story point again and repeating it and what you really need to do here is run these until your gear is at that level of the enemy no matter the world tier you are playing on I mean yes for sure you can get away with one or two pieces probably being a little lower but for the most part you want to make sure that loot is at the same level of the enemy you are going to face I will add also although I don't like partying with my materials just yet there are vendors within certain areas notified with certain symbols which do sell gear on the level you will need also but they do take eight of the materials so I prefer the chest runs now when farming chests then getting that gear when it does drop on that max level for that world tier you are in prior power on weapons and armor values on the armor obviously do kind of fluctuate but as long as armors are all relatively around that same level you should be fine and same goes with the weapons now what happened with me yesterday was and this is also important to note I had a max armor and weapon levels for the current world tier I was playing on and then I leveled up my character leveled up from a level 20 to a 21 this in turn meant that enemies also leveled up too all that armor and weapon I'd farm from the chest all of a sudden felt a little weaker so that's very important to note guys if you're in the middle of a certain world tier your armor and weapons are on level with the enemy if you yourself will level up for your earning exp so will the enemies for your weapons and armor will stay at the level you got them at so if you start to struggle or get to a point where you're struggling it may be worth running the chest farm again now once you have farm chest people and got that loot depending on your current level and even if the armor and weapons you got are not epic just res it's also very important to apply the correct mods to them you do this via doctor as a heady at the camp make sure you're using mods which affect and benefit the abilities you are using first and foremost if you are happy you have enough assistance here you can apply mods to help weapons and apply an extra damage too this is important as I know it's early stages of the game but people think it doesn't matter it truly does mods on gear help a ton but yeah guys if you follow the guidance I've given you right now you'll find that those extra leveled enemies now you are on par with them ain't all that bad I mean no matter what you do guys when you progress through world tiers it gets harder much harder but never impossible as long as these steps are taken into account you can also try mixing up those abilities and weapons too don't be scared to swap things out once in a while I mean yes I know you get attached to those weapons I want to use them forever but right now in these early stages I guarantee you guys they are not worth it but yes guys on that note the end of the video has arrived if you enjoyed it leaving a like really helps me out if you're new around here and want to see more outriders on a daily basis be sure to subscribe and if you never want to miss a video upload you can turn notifications on by hitting that bell button but guys I appreciate you stopping by I hope to see you on a stream later today and I will catch you soon


Media Partners, Viacom 18, Star Sony, TV 18, Zee Danik Bhaskar, GMR, Hindustan, Hindi, Hero FinCop, BTIVL, Mahindra Fin, PVR, Idea, Nickelodeon, Inox Air Products, Cameline, Dirt, ONGC, Phinolex, Olacab, IRCTC, CII, Vodafone, Live for Indigo, Airtail, MACCAM, Apollo, Dr. Reddy's, Radio Partners, Fever FM, Big FM, Radio City, Red FM and My FM. Big round of applause for all our supporters and partners. Thank you. Thank you very much. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. This is the one of the most important thing we can do it to our planet. So, my humble request is to all the children, to all the parents, to all the media, please support this thing, because if you don't get water, then nothing will happen. So please, it's my humble request and I just wanted to say thank you so much, sir. Thank you so much. Thank you, sir. Now, I would like to present my humble request to Mr. Dinesh Sharma, that he should come on the stage. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.


Good morning, everyone. Thanks for coming to the lighting talk. First, let me introduce myself. I'm Guo Shan. You can call me Jolie. I'm from AWS Cloud. We are a pure OpenStack player in China, and a startup company from 2012. We have our enterprise customers to build and operate OpenStack Clouds. I'm a developer in this company and started with a focus on Keystone. Okay, let's we will introduce what's the mistake hack done. Now this activity called boxmush. Then I'm going to put down my impressions and observation about these incredible events. It is the activity that guarded the most, guarded the core viewer from overseas and most top Chinese OpenStack developers get together. And in the last five boxmush, over 300 hackers contributed more than 500 bucks to the community. It's really a huge, but the boxmush consists of three parts, programming marathon, presentations, and two buildings for the first part. In the first day, all the developers will be divided into the groups by the project they involved in. And two for better communication and discussion. And each groups will have a core viewer stand by to review patches and vote for the merges. And for the second part presentation, each there will always be some well-respected developers from others, from many companies to give the attendees some presentations to share their new projects and the latest trends. Always thought-provoking and inspiring. These have helped hundreds of developers to catch a glimpse of the OpenStack future. And in the last day, the host will organize the team building in outdoors for relaxing. And maybe it is, you can catch a glimpse, you can snatch a moment of leisure during workday. It's really relaxing and you can keep a closely contact with the people you match during the OpenStack hackathon. And I have participated in these bugs much for twice. The first was in Hangzhou is a beautiful city and has held the G20 Summit in 2016. And I have participated in that activity in 2016. I just started to give contribution to the community. And just one ordinary afternoon, my colleagues asked me if I want to join an OpenStack related activity. At first I hesitated for lack of confidence because I was really a newcomer to this activity. But under the encouragement by my colleagues, I joined assigned for this activity. Well, it turned to be a real great activity for you can make new friends in the community and you can connect with their community ID with live ones and working closely with them. So in the first day, after the introduction, I had some discussion with other Keystone developers from other companies to discuss some Keystone related things like Keystone Federation Research and the token provider chosen and further development. You can learn tips and tricks to gain a better understanding of OpenStack with closely working with others. And the second year, I take part in the second OpenStack in Shenzhen. And six months later, I think I become more familiar with the OpenStack community as well as this activity. So this year, I really get some new, get some real connection with this activity. Well, there's a launching net. All the attendees will vote for the valuable box fix by the group and the one OpenStack superwoman among all the women developers in this activity. I think this price is valuable and luckily enough, I won the second, I won the OpenStack superwoman in my second box match trip. It's really a pleasure to launch the community, the organized community set a place for women to make this activity more diverse. I hope this speech and to introduce something more to let more people know about this activity and to take part in it. Thank you.


What's up everybody welcome back to the channel I'm evil rabbit here I'm forza motorsports 7 so if you guys tuned in the last episode you guys know I did unlock an achievement and I was scouring trying to find this car and I found it I just had to go accept it so we are staring down that Forza edition Mazda MX-5 wide body with that nasty big spoiler like Mike Amaro so today we are here today to do a full drift build on this car this is a car I've been wanting to get to do a drift build on so we're gonna see if we can't get this short wheel based light little rocket ship sideways and have a little fun so we're gonna hop right into it we're gonna get the tuning on this car going I have not touched it yet so we are gonna go and take a look at what we're running with I believe we are probably running a stock motor we are we may switch it up we may do a four rotor I'm not sure as for aspiration I think we're just gonna straight up we're gonna turbo it to start and uh we're gonna go from there we're gonna leave I believe oh we can go sport so it's on stock sport and race so we can go sport tires we are gonna do sport tires on this car and we're gonna keep 245s in the front and 255s in the rear we definitely got to change those wheels not a not a huge fan of those big spoke wheels I am feeling some 1552s though so we're gonna go with those concave 1552s I think we are going to stick with the 18 inch wheels that are on the car I hope this car gets low enough to where it's decently you know dropped we're gonna throw all transmission drivetrain everything on as well as a diff nope we don't want that diff we want that diff there we go and then we are gonna go into suspension uh we're gonna keep the sway bars off we're gonna put a roll cage in it we are at 2,100 pounds I believe we're gonna leave that weight there and now to add power I believe it's already on race suspension so we should be okay we see how much power we can get out of this turbo stock motor like I said we may be switching to a four rotor depending on how this thing drives definitely intrigued with the short wheelbase haven't drifted many me out as my friend who ate my hamster has drifted a lot of them and uh he's pretty good with it so we're gonna see how this little mx5 wide body does and now we're back down that's 2,000 pounds this thing is light for sure so we're at 603 horsepower and not a lot of power but like I said we are gonna probably just see how this goes first and then we will modify it from there right so now let's uh see if we can't find a pretty interesting paint job for this car I was hoping we could have a you know man like with that uh we do have one but I do not believe that is his new car that's just a Mazda racecar car so we're gonna see maybe if we can find a formula drift let's see let's do formula D any veins got nope nope none all right so let's do one last search we'll just do drift if not maybe we'll just uh what am I spelling maybe we'll just leave it how it is and just rip it because you know it may not handle as well as I'd hoped but we will see I'm determined to try to get this thing going sideways it looks pretty nasty and uh hopefully we can get it lowered enough to make it look good so I think we're just gonna go with a basic um just gonna do a basic paint on this car we only have red manufacturers I kind of feel in a little bit of a blue though so we're gonna drop yeah you know what we'll just leave it red and uh we'll just throw on some white wheels just you know for the haters his white wheels on the red car but I do like white wheels there are a pretty sweet additive Ryan Turk is rocking the new white wheels on his car this year and his car is red so you know haters gonna hate so let's kick into tuning this and we're going to dart off by dropping the tire pressures we'll do a basic tune on it and we will send it to the track and uh see how it goes this thing is already got a lot of camber in here drop that down a little bit and then we are gonna see how this thing handles not sure what track I want to send this to yet but we are definitely gonna send it yeah that thing's high drop this make it nice and soft I hopefully that drops it enough to make it look halfway decent because right now it's uh it's pretty monster truck so we're gonna leave that all there we're gonna drop our braking down not that much and then we're gonna kick our diff up and go with that all right so it's a little bit lower not as low as I would like it to be there's still a bit of a fender gap but uh we'll go with it and we'll uh see how it runs we are not gonna run at there we're actually gonna run drift and I have not drifted at Maple Valley in a few so I feel like we're gonna hit Maple Valley circuit and see if we can get this thing sideways here at Maple Valley so if you guys have this Mx5 and you guys have built it for a drift tune let me know if not maybe you guys are uh don't have it but I did get it in the forces on so make sure you guys get it yourselves um it does look pretty aggressive though I mean hopefully I don't like this car more than I like my Camaro I'm gonna be switching cars up real quick with four pound one of ESDA but you know we will see so we're gonna get the wheel cam turned on we got our g920 off set up with our energy wheel and uh we're just gonna go straight into it it's just kind of cool it being a convertible I wish it was a full cage but so stock turbo motor you see how this thing goes sounds pretty sweet I don't think it has the power though for this uh handling on it's pretty well though uh yeah I think the power is definitely not there as we completely just wrecked our brand new car the power is not there for the sweeper as much with the sticky tires but oh man this thing handles very well it has some pretty decent lock where I definitely can feel some changes that we're gonna have to make on this car and uh yeah I can definitely tell some changes that I need to make in suspension but uh first impression of the car though sounds sick looks sick I liked that little flutter I was hoping I'd hold that in there but I held the handbrake too long yep so I definitely feel I need to make some changes to suspension a little bit but it's close definitely close so we're gonna go make those changes before we are make a complete fool of ourselves with this car and um so we're gonna go into tuning I'm gonna tune this a little bit I think we're gonna leave tire pressure gearing gonna go for a little bit more speed alignment we're gonna knock this down we're gonna knock this up a little bit and knock that as well and then I think we're gonna pop this one up a little bit to give it there and I think that's the mild adjustments we're gonna make I think we're gonna change tracks though um let's see where should we go go to Magello go to Prague we go to Rio uh we're gonna go to Lime Rock we're gonna run at Lime Rock real quick was not sure where I really felt like running this but we're gonna run at Lime Rock we may end up throwing this at Long Beach to final this off to see how does it a Long Beach run but uh Salamiaba's uh definitely got some uh got some pep in its step but I think that quad rotor might make it a little bit faster so we may switch to a quad rotor after this run but I do like how this how this sounds with that little flutter those wide tires is sticking out these are changes we made work that does feel a lot better now oh and so you hit the grass like that so short wheelbase definitely something I gotta get used to because uh I'm used to long wheelbase cars and this car is also super light so it's making this a little bit snappy on transitions and it's not how I want it to be so we're gonna make a couple more adjustments I think we may have made it a little bit worse so we're gonna tune this again going to leave the tires leave the gearing bump that up bump that back down and we're actually gonna bump that down a little bit and we will give this one more go for we maybe swap motors might be the motor it might be the weight distribution in this car is a little bit off for my style of driving it might be good for you know somebody else's style of driving but mine's a little bit different I guess for this car so a little better yeah it's very snappy with the short wheelbase but it's definitely a lot of fun it is kind of cool to see it as a convertible though you'll see the driver so this car is actually a lot of fun to drive if you don't have one I would uh if I were to act am I getting one it sounds amazing which we will probably lose that sound once we go quad rotor but we're gonna try drifting this thing in first person right now I was actually trying to get to a different view but we're just gonna run it out here so the short wheelbase definitely a challenge to drive uh I haven't really messed with really short wheelbase cars before so this is a new thing for me and uh it takes a little bit of getting used to that's definitely uh something to be said takes a little bit getting used to the short wheelbase and that's really bumpy too wide I just love that flutter sound it sounds so good and I think we're gonna change it to a quad rotor and make it sound a lot worse but maybe it'll sound even better we're not sure yet so we're gonna go upgrade this we are gonna swap the motor to that quad rotor race motor puts up 26 or 2166 so I believe we do lose our turbo and we just have 736 horsepower straight quad rotor race motor um we're gonna leave all the other tunings the same and we're just gonna send it this miata is definitely uh oh it's an angry V now and all it does is crackle so definitely different sound but the feel of throttle response is pretty nice the guy that was following me in the last episode was running a quad rotor and his fd okay so I may like this thing in a quad rotor um not gonna lie I think the weight bias has changed a little bit and uh the smoothness of the revving and the lack of turbo lag is I think more my style because that's why I am running the Camaro because I like to straight V8 and power on command and this is uh pretty power on command but it is still very twitchy I think some more fine tuning with this car would be pretty uh pretty awesome actually give another run here too much but we saved our points though and uh right back in the drift so quad rotor is definitely uh pretty awesome in this little mx5 it sounds uh very angry it's got a lot of cracking but it is definitely a lot of fun a little clutch kick some mongees so I think I think I may have to spend a little bit more time on this car to get the suspension dialed perfectly but right now it handles pretty pretty well it's definitely a fun little car to drive especially because I'm not used to that style with the short wheel base but I think we are going to head to Long Beach to give it a quick fd run because uh you know fd starts tomorrow qualifying starts tomorrow at Long Beach I believe it starts at four o'clock eastern time starts qualifying tomorrow on uh you know the fd live so I believe that is actually one o'clock their time I believe so we're gonna run this one or two laps here so I hope you guys enjoyed this little uh trial into these short wheel paste drift cars I was super excited when I found this car and I wanted to do something with it I may mess around with it some more and uh maybe make a full you know very well-tuned when I spent some more time on this car but this car it looks amazing I'm glad to see this little uh wide body mx5 in the game and I'm uh excited to see some of the other Kyle Moan bringing his mx5 back in fd this year I believe Matt Mike Woodette as well is coming back and uh excited to hear those uh rotary screaming around the streets at Long Beach echoing so I wish we could turbo this car though when we could make a mad Mike Woodette build but we can't so we're gonna run this 50 roll the echo off the wall was not expecting to snap that hard right there so we're gonna rerun that but this uh this thing sounds mean it's a lot of fun to drive if there are some guys out there that got some good Miata tunes that are subscribed to channel let me know your game or tag if you got the tune up I'd be very very intrigued to try some Miata tunes I may look and see if there's a tune for this car and see you know what it drives like and see if I can't get my own tune to feel as good as say a tune that is downloaded that feels very well so we're gonna give us another go the entry wasn't bad the corner of that bridge so you guys know you guys can follow me on facebook twitch twitter and instagram all of which are found in the description box below as always you know guys I like thank you guys for watching and I do appreciate all the support yep there's some needs some fine tuning done to this car so until next time guys I'm evil rabbit and I'm out


Do people not realize that under Donald Trump, America was energy independent? Since day one, Joe Biden has systematically disassembled all Trump's policies that made America energy independent. Now, Biden's energy secretary is literally laughing at the American people for paying high gas prices while blaming OPEC. We didn't need to be relying on OPEC. Joe Biden made that happen. Mr. Burgess, Michigan, it is $2.89 a gallon. I guess that's better than in California. What is the grand-home plan to increase oil production in America? Oh, my God. That is hilarious. Would that I had the magic wand on this? As you know, of course, oil is a global market. It is controlled by a cartel. That cartel is called OPEC. Make sure to check out my new Let's Go Brandon t-shirts. You can find the link for that in the description or pinned comment.


Prayer is not all about receiving. In fact, it's more about becoming. More than it will change anyone or anything else. Prayer will change the one who prays, caught up in the overlap of heaven and earth. You'll find yourself being transformed by your contact with the heavenly dimension. It will change the substance of who you are, nature and character. For every moment you are praying, you are changing. Whether you see the immediate evidence of that or not, it's impossible to accomplish nothing in true prayer.