So maybe some of you, maybe all of you, have your own Apache Meso's cluster running. Everything is going great. That's awesome. And maybe you've got applications running in production as well. So let's ask a few questions. Are you able to guarantee capacity for all your applications exactly when they need them? Are you able to optimize placements if that's important to you? Maybe there are some batch workloads that can take care of affinity or locality or anti-locality, right? Do you keep your cluster size elastic or do you provision for peak if you're in a data center environment? That would be true. And are you able to optimize your maximum footprint? Well, these are the questions I'll try to address today. My name is Sharma Podila. I've been at Netflix for about four years. I'm part of the, what's called the edge organization, edge engineering organization. And I worked on a couple of projects that are relevant to Meso's. One is called Mantis and the other Titus. I'll briefly touch upon them. And also we open source the Netflix FENSO scheduling library. Before that, I spent time creating batch schedulers. So this is what we're going to cover. I'll start with a brief context on what are we trying to solve? What did we start out to solve? And my title of the presentation has the word juggle. Why do we need to juggle? We'll take a look at a few challenges that are specific to large clusters and then dive deep into what we've created, how it works for us and share some details with you and then a peek at what we are thinking about working on next. So when we started about three and a half years ago, one of the projects that was looking at Meso's was called Mantis. It's a cloud native reactive stream processing system. It was built to answer certain real-time queries like, hey, the Netflix service is running okay, but maybe it's just a handful of users in one corner of the world are not able to stream a few episodes of a show which gets lost as noise in the overall signal of availability of Netflix service. So doing high cardinality anomaly detection, things like that. And for this we built a scheduler on top of Meso's in order to run containers that are doing stream processing. And there's a lot of interactive exploration of data that users can dig into by putting in new facets and querying what's happening in real time. Around the same time another project that started is called Titus and that's a Docker container orchestration system. It runs on top of EC2 specifically in the VPC environment and it integrates into the rest of the Netflix microservices ecosystem, the discovery monitoring and software-based load balancing and things like that. And Spinnaker is our CICD pipeline and a common UI to make application deployment easy with all its pipelines. So both of these projects were starting out around the same time and what we saw was that what we needed from a cluster manager was a support for heterogeneous mix of workload because the workloads are going to vary not only in terms of how many CPUs each task might ask, memory and network bandwidth, etc., but also in how critical they are. We have a mix of some being more critical than others and their runtime profiles. Some of them are short running batch tasks, some of them are long running batch, but some of them are perpetually running services. And then the resource demand, it varies over time. Netflix is definitely dependent on the time of the day in terms of how many active users there are and that means Mantis has a different amount of data to process and it actually varies about 5x from peak to trough. And similarly the number of containers run in Titus also varies over time, especially for batch systems where work comes in sporadically in lots of them and then just goes away after they're done. So, okay, all that sounds fine, but why juggle? We need to get one thing out of our way which is if you had unlimited resources, I can tell you there's no need to juggle. Life is simple. And I didn't say infinite because we just need practically unlimited as in more resources than we have demand for, right? If we had that, there's absolutely no need to juggle. It's very simple. But the other question that comes up, especially for us is since we run on the Amazon cloud and it's an elastic cloud, well, don't we have an unlimited supply of resources whenever we need? We just go to the cloud and ask for more. Why? It would seem like that's the case. And if you were to sort of represent that as demand versus supply and look at the whole aggregate of all resources we use, maybe it does look like that. The demand is less than the supply, so everything should be fine. But when you start looking at it, there's not just one server type in the cloud. There are so many different instance types, right? And when you start looking at it, it looks like, hey, for some instance types, maybe the demand is less than the supply, but for others, it's actually the opposite. So we do have certain workloads that need to use certain resources for which the demand is higher than the supply. So there is some demand versus supply juggling that we will have to look at. And the other is efficiency. Some workloads need a lot of memory. By the time you pick an instance type that can satisfy that, you're automatically getting so many CPUs that that application is not going to use. So you're going to start seeing holes in utilization. So can we do something about it, improve the efficiency? And then there's different workloads types, not only in criticality, but there's a lot of pre-computes that are done for production workloads to do data lookups. There's experimentation, and then there's testing, and then there's something what I call as the idle soak, which is, this is not super critical workload, but if I can run more of it, it helps me maybe converge in my algorithm, better improve my conference intervals. So if there's any idle cycles, just run this, right? There's all kinds of workload. So, okay, are there any specific challenges to large clusters? So by large, I don't necessarily mean only in the number of servers, number of agents that you use. And if that's large, well, that's a large cluster, but large is also in terms of how many users do you have that are trying to do different things? How many different use cases you have? What's the differences in the kind of resources that the jobs need? The variety could be large, the number of servers could be large, or the number of users could be large. So when you start looking at scheduling, you can think of doing a first fit kind of an assignment, and it keeps things pretty simple. And given the right environment, it can actually be very fast. You can probably achieve constant order time complexity for first fit kind of assignments. However, if you start doing the most optimal assignment, this can be expensive computationally. And even if you were to not reassign already running workload, just figuring out assignments for the pending workload can be computationally expensive. Ideally in the real world, we want to stay somewhere in between as close as possible to the speed, but achieve as much optimal assignments as possible to the other end of the spectrum. That's our goal. And speed is important for various reasons, but two things that I like to point out are if a scheduler were to be slow, while it's figuring out assignments, there are servers that are becoming idle, efficiencies lost. And one could argue that if the assignments were figured out, assuming those servers were full, and in the meantime, they become empty, the schedule is actually incorrect now. So speed is definitely a concern. So with all this in mind, our initial goals were that we need to have a cluster manager and a scheduler that can take multiple scheduling goals in mind and achieve them. We need to be auto-scaling our cluster size, as we do with a lot of things at Netflix, trying to be cloud-native and use and pay for the resources you need. Extensibility. Extensibility is something that, well, I've learned, a lot of people have learned that if you try to keep adding one new feature at a time into a scheduler after some time, it feels like you're adding a Band-Aid over a Band-Aid. And instead, it's easier to design a scheduler that is easy to extend, so that it has to be a goal from the beginning. But very soon we figured out that there's a few more goals we need to add. Security. If we are going to have multi-tenant workloads, different applications, then we need to have a good security story around that. Capacity guarantees. And can we reason about fail-to-execute failures in operations? So let's look at each of those. So as far as multi-goal scheduling objectives go, we can think of four different camps that have an influence on how you should do resource assignments, right? The data center of the cloud operator is interested in making sure while they can do maintenance, they can make sure that the cloud footprint is small, etc. So they're interested in making sure the scheduler behaves in certain ways to achieve their goals. The application owner, on the other hand, is interested in making sure their application gets the best performance possible. If I can get a performance by buying my own machine and running my application, running it in your system should have a similar performance characteristic, if not better, right? And high availability is another concern. Don't put all my tasks on the same machine, same rack, etc. And security concerns are that at least in Netflix, we have certain applications with certain security profiles that can only access only certain other applications, right? Everybody's got the security problem. So if you're going to put multiple applications on the same host, you still need to guarantee that that will be true. Cost is an interesting thing. Cost could mean so many different things. It could mean, hey, use the cheapest instance size possible to get the work done. It could mean in a data center, make sure your power and cooling costs are under control. You can actually schedule things and save on power and cooling. So things like that. So auto scaling, like I said, Mantis has 5x or more peak to trough variation in the amount of data to process. And we don't necessarily want to size our cluster for the peak there. Similarly, Titus has thousands of containers or hundreds of containers running at different points of time. It turns out scaling up is, well, it's not super easy, but relatively easy. You can, for example, watch for some kind of metrics that tell you, here's the demand, it's getting close to your cluster size. And then if the buffer is very small, then you scale up. So scale up can be a little bit easier. But it's a scale down that's harder. And it requires you to do bin packing. So in the first row of these four hosts, I've got a similar number of CPUs being used, about 50%, but they're spread across all the machines. And if I need to scale down, I'll have to move those applications somewhere else. But instead, if my scheduling actually took that into consideration and did bin packing, then it leaves two machines completely idle and it's easy for me to scale down. So that's the basic idea. However, there are other aspects to it where batch workloads can complete at different points of time. And then can you actually look at that, estimate the expected runtime and put them together so at about the same time, the entire machine is going to free up. There could be sophistication, but this is the basic idea. And for security, and for security, we actually find right now that we've got applications, we use security groups on Amazon. Some applications have a single security group. Some of them have multiple, and there could be a mix of them. We'll need to make sure they are isolated. And we look at capacity guarantees. What we're seeing is that here's dozens of applications that are going to be run on the cluster. How can we make sure they have the right capacity when they need to? And when people think about doing this, there are, broadly speaking, two ways to think about it. One is priority, which is on the right-hand side of the slide. And the other is some kind of a quota to say, I'm going to give more quota to the more important workload. So when you look at the quotas, often it's a static fragmentation of the resources to say the critical, for example, gets 75% and the other one, flexible or flex for shard, gets 25%. But what happens when there's a surge in the critical workload? If they're limited to 75%, well, you're in trouble because that is the critical workload. So then you need to vary the quotas, maybe. So that's one problem that we could run into. And the priorities may seem to work because first you make sure the highest priority workload is run and then the others. But then that can starve resources for the flex tier. And even though flex tier is not critical, for example, it's not user-facing services, you still need to get batch workload done on time. And if you're going to starve them, then it's not going to affect you today. It's going to affect you tomorrow maybe. So there's still certain throughput you need to guarantee for batch workload, even though your critical workload is more important. So just the strict priorities is also not going to work. So those are some of the thoughts that we go through to guarantee capacity. And for failures, I'm going to talk about specifically the failure in a job to get launched. Somebody submits a workload. It's not running. You've got thousands of jobs submitted. How do you know why this particular job is not running? Okay, if it's not running, what are the resources that it is asking that are not getting satisfied? And how many servers are even available to satisfy that but are failing at the moment? So these are some of the questions we want to be able to answer. So with that context, what did we create? Here's the overall architecture of what we have. We're out on EC2. We've got Mesos running there. And on top of that, we are running two frameworks, one called Titus, the other called Mantis that I spoke about before. Both of them have abstractions on jobs. Jobs are a collection of tasks and there are a few different types of jobs, batch service and then the stream processing job as well. And both of these frameworks, they use the FENSO scheduling library that I referred to before. So let's look at this in a little bit more detail. So the scheduling strategy that FENSO has is that when we look at tasks and then say, here's the potential list of agents that we could run them on, some of the agents may at the moment fit the task perfectly or some of them may fit okay. It's not bad, but it's not a perfect fit. And there's like a whole spectrum there. Also, some tasks are urgent. Maybe they need to complete right away or they have their service type critical, they need to run right away or some of them are not so urgent. So the general strategy in FENSO is that if it's either urgent or it fits perfectly, let's go ahead and sign it. If not, let's keep it pending and look for other agents where they may fit perfectly. So that's the general idea. So FENSO is actually open source and it can be used by any scheduling framework, any mesos framework that runs on the JVM. And then it provides you extensibility. You can write plugins, which are basically simple functions that you tell FENSO here's my function. It gives you cluster order scaling if that's important to you. There's tiered queues with weighted DRF within a tier. And it gives you a control for speed of assignments and optimality. And actually, importantly, it also gives you ease of experimentation. So if you want to write new plugins or new scheduling algorithms before you put it out into the wild, you can actually say, here's a snapshot of my production workload. Let's run it in FENSO and make sure that this new plugins would actually work well before you put it into production. So it lets you experiment. That's the URL for where you can find it. This is roughly the algorithm that FENSO uses for each ordered task. And we do have queuing. For all available hosts, we start validating what we call hard constraints. Hard constraints must be met in order for the task to run on that. And then we evaluate scores for what we call a fitness function and soft constraints. And then we don't need to do this on every agent. We only need to do this until we find a fitness score that we think is good enough. And that's where the speed comes. If we relax the criteria a little bit that, hey, the score could be low enough. I'm okay with that. Then you get speed. If you make the criteria to be, I need the score to be high, then you get more optimality. So you have that control. And then we pick the house with the highest score within that. So the constraints, both the hard and soft constraints and the fitness functions are the plugins that you write. FENSO comes with a few built-in ones for bin packing, but you can write any fitness function that you want. So what do we use in our system? We definitely use the CPU memory and network bin packing that FENSO already comes with. And to understand how it works, it's very simple. Let's take the example of CPU bin packing. When we look at an agent and a task, let's just assume that all single CPU tasks for this example. We've got five hosts here. Host five is already full, so it's obviously not going to fit it. But we evaluate the ratio of the used CPUs. If we were to launch this task over the total CPUs on the host, that basically gives us a fitness score for CPU bin packing. Similarly, you could do that for memory, network bandwidth. And we also do that for the runtime profiles, so we can sort of dynamically segregate short-running tasks from long-running tasks. It helps us in downscaling, like I was saying. And speaking of extensibility, recently we added another fitness function where we can control or limit the number of concurrent starts happening on machines. This has to do with more on the executor side, the whole docker ecosystem of how many tasks can you concurrently start downloading images and all of that stuff. So we wanted to get a good control, so we added a fitness function for that. And then we combine these. So you can have multiple fitness functions and compose them together to form your overall fitness function. And we give them weights to say, hey, bin packing is important to me. But runtime segregation is also important. And so is control on the launch. So I'm going to give you different weights. So we're playing with weights to see what weight works best for us. The hard constraints, we used two hard constraints today. One is for GPU server matching to say that a host that has GPUs will only run a task if the task is requesting the GPU. Simple enough. That's just a hard constraint we put in, and it automatically does that. We also have some resources here marked for certain kind of tasks. So we use hard constraints for those as well. Soft constraints are mostly specified by the users at submit time. And the popular one is to balance the tasks across availability zones. Amazon regions have multiple availability zones. And by spreading them, you are making it highly available that even if one zone were to go down, your application is still available. So they specify this declaratively to say balance my tasks across the availability zones. Some services, especially those with a low instance count, also require us to balance them across hosts. So while it's a cloud, an instance could die for some reason and come back later. And if one host were to go away, we don't want too many of those instances to go away, especially for those small services. So how do we combine fitness score and soft constraints? Soft constraint also gives us a score to say, yeah, this constraint is met perfectly or this constraint is sort of met. It's okay. The constraint itself is not failing. So if we have such constraints, then we can combine that with the fitness function. So the reason these are different is that fitness function is sort of more globally applied to the cluster. The people who are looking at cluster level optimization and writing fitness functions, whereas the constraints are being written by applications to say for my application, I want this soft constraint. So then we combine them with currently these are the weights that we use to combine them. So it's 40% the global fitness. We give more weight to the user specific constraints. So FENSO has a multi-tiered queue setup. You can theoretically have any number of tiers, but in practice it makes sense to have a handful of tiers. Today we use two tiers, the critical and the flex tier. And what we mean by critical and flex is you can have important applications running in either tier. What we mean by critical is that it's critical for the task to be launched right away. Whereas for flex tier, it's okay to launch them with a little bit delay. I'm okay with that. But this is still important. But how quickly you launch them. So for example, a user facing microservice that's latency sensitive will be in the critical tier. Whereas a batch workload that's okay finishing in the next hour or overnight will be in the flex tier. They both need to be guaranteed some capacity. It's the difference is how quickly they need to be launched. And within each tier, we have multiple applications. So it's multiple buckets. And we do DRF, which is dominant resource fair share across these buckets. It's a weighted DRF. So one application may have more weight for the share that it gets within the tier versus another application. So when Fendo looks at different tasks, it goes through the tier zero, then it goes to tier one and then does DRF there. If there were other tiers, it would have gone down each tier. So this also, we also wanted to make sure that the interface to the users is simple. So users have to do two things. One is when submitting workload, they specify an application name. And then separately, one time specify how much total resources this application would need. And that's in the form of, here's the container size I anticipate. It's a four CPU, eight gigabyte container. And I think I'm going to run about 120 of them or thousand of them, whatever the number is. So once you give that to the application, then the system is able to look at that and say, okay, I'm going to guarantee this capacity. Based on that, I'm going to choose instance type. The system does this. I'm going to choose instance types that have at least four CPUs. So I can't guarantee that your container will ever fit, even if I have in aggregate more CPUs than 120 containers, right? We also want to make it easy for people who want to experiment or running really small services. So there's no overhead in creating this SLAs. So there's a default catch all bucket. We give it some buffer to say experimentation should run fine there. And once experimentation is done, they want to make it into full production with guaranteed capacity, then they set up these SLAs. So we don't need to go too much into detail, but what we're trying to show here is that if we had, say, dozens of applications, each of whom have given those SLAs, how do we figure out how to size our clusters? Especially since we are going to be auto scaling the cluster size itself, how do we figure out how many instances do I need at the moment? So we do that separately for each tier. For the critical tier, since we need to guarantee near instant launch time, we sometimes end up having some idle capacity there because if the service spins up more instances, then we can launch them right away. However, we still ought to scale based on some logic in figuring out the buffer that we can have and still be able to guarantee near instantaneous launch time. Whereas for the flex tier, we actually keep the current size of the cluster exactly where the demand is. So this is what we mean by if you launch more tasks in the flex tier, we will launch them. We're going to guarantee your capacity, but you may have to wait for us to spin up a new VM underneath in the EC2 cloud. So that's where the difference is. So reasoning about failures. This slide has small font text. It's okay if you can't read all of it. The point to show here is that in our server, we have an endpoint on the control plane that gives you failures for a task that is staying in the pending state and not getting launched. This is just a raw JSON output from it. What it's basically saying is that here's the constraints, the hard constraints that are failing for this task. In this example, it says, well, you're not asking for GPUs, so it's not going to run on these machines that are GPU-based machines. And then the first one only runs on agent clusters and gives you two cluster types is basically saying that, like I was referring before, certain kind of tasks are earmarked to run on only certain machines. That's how it's set up for us right now. And that's why it's failing that constraint. And beyond those constraints, there are machines that satisfy the hard constraints but are still failing because they don't have enough resources to run this task right now at the moment. So it tells you for each of those memory requirement is failing on these machines, and it tells you by how much. And for network bandwidth, same thing. And for CPU. So it's been useful for the cluster operator to figure out why is the task not running at the moment. So while I'm coming towards the end part of my presentation, so what are we thinking about next? There's several things, but I wanted to highlight three here. One is task evictions. Some people like to call preemptions, evictions. They're similar, but some differences. But regardless, right now, we seem to like calling them evictions. So by task evictions, we mean here's some idle resources that need to be up and running to guarantee capacity. But maybe I can run some other lower priority workload right now and then evict them later. That's one example. Similarly, when we have weighted DRF across a tier, if one application is not running as much, we can let the other applications run more and then evict them to balance out the weighted DRF algorithm. So those are two examples of where evictions could be useful. Evictions could also be useful because of noisy neighbors. You thought two applications will do okay on an instance, but you notice there is an impact to one of them, and then you can evict and maybe migrate some of their workloads somewhere else. So lots of interesting discussions there. Some of you probably have thought about this, maybe have solutions. We would love to talk to you maybe in the Q&A after this or after this session any time. Okay, so I covered noisy neighbors. So besides evictions, I think one of the challenges we have with noisy neighbors is we're not sure yet what to monitor. How do we measure the effects of noisy neighbors? We have some ways of looking at them and we've come up with, okay, let's keep these applications apart, but we want to be able to dynamically do that. How do we guarantee that is a service workload will meet its latency SLAs? And similarly throughput SLAs for batch workload. So I think there's a lot of work that could be done that would be very useful there. Automated rollout of new agent code is another pain point for us at the moment. When you've got lots of agents already running and you want to introduce new agents with new code, then I wish there was an automated way of doing rolling upgrades, which can take into account the specific measurements we would have to say that the new code is working or not, right? So some kind of automation there. We're trying to build that. So there's probably more. I wanted to highlight these three and then I would love to hear from others what else that you guys working on or if you worked on thought about some of these, what you have to offer at this moment. So let's actually open it up for questions that's all ahead. And slides. This one work? Yeah. Excuse me. For FENSO, are you thinking about putting in support for the maintenance primitives and how to prevent FENSO from scheduling on something that has a maintenance window or things like that? Yeah, that would make perfect sense. We are not using maintenance primitives in Netflix right now because of how we deploy agents. We have more of a red black kind of deploy of agents. So that's one reason we do not. However, what we are looking at is we have the case of bad agents or agents going bad. Some of them are dead on arrival, but more interestingly, some of them go bad after some time. Maintenance primitives may be useful there. I don't think we have a specific use case for maintenance primitives, so but it would make sense if somebody wants to work on it for FENSO. We would love to collaborate and see a PR. Thanks. If you know for sure what a workload requires in terms of memory, disk, network, stuff like that, why would you have a noisy neighbor if you've properly specified what a container is going to need? It's probably the inability for us to specify everything an application needs. I think it's easy to think of it in terms of what we know, CPU, memory, amount of memory, and amount of network bandwidth. But there's caches on the CPUs, there's the whole memory bandwidth issues, pneumoness of the architecture on the CPUs. There's so many other things that are happening that impact application performance. So if you were to run that application in isolation on that machine and you would still use the same number of CPUs versus with other applications mixed, there are performance implications. There's a question here. I can speak to the noisy neighbor problem a little bit. Intel's done some research on that. One of the things it's finding out in noisy neighbor scenarios is oftentimes replicates of the same tasks that are given exactly the same resource requirements, exactly the same things. They can be each other's noisy neighbors. So once you actually know what something does require, you instantiate hundreds of those and they can actually interfere with one another, which is an interesting point. But the question I wanted to ask you has to do with whether you've considered applying predictive analytics to determining noisy neighbor scenarios in the future, or being able to squelch those before they happen. Yeah, I think that's a good question. Have you considered that? I think we've dreamt about it. We haven't solved it. We touched upon an aspect of that in the user panel this morning, so that would be wonderful to have. Yes. I was curious about the availability zones being a soft constraint and whether that can allow services to end up being deployed in a way that are not highly available if that constraint happens to be satisfied and scheduled on that note, even though it's not in another availability zone. Yeah, that's an excellent catch. It's a soft constraint, not a hard constraint, and it's deliberate for one specific reason, which is if you were to have a zone outage, we use three zones right now, and if we were to have a zone outage and you launch a service, then one third of your service will not be up and running if it's a hard constraint. That's the reason we make it a soft constraint. But the downside is that if the zone is down, then the service is only running across two zones. Right now, we haven't solved it completely, but what's coming later is dynamically reshuffling them to make sure that they are well balanced, but we haven't done that work yet. FENZO right now has a dependency on mesos .21. What are the challenges to bring it up to 1.4? I think it's the latest mesos. So we run, while there's two different frameworks, we run it in Netflix. One of them is running at 1.1, or if not 1.2, and the other is running at 1.0. Something. Then when we do the dependency management, of course, that wins over what FENZO provides. FENZO has, we've not put the later mesos functionality into FENZO, so it's able to stay a little bit older. If we were to move it to 1.4, I think FENZO itself will work fine. It does not use any specific mesos features right now. We haven't moved it because it was not needed. There's no other reason. But I think, I don't know if you were also implying that there are newer features that we need to add into FENZO, but I think we haven't done that yet. We would love to get contributions if somebody's focused on it. Yeah, mostly just knowing the challenges of what it would take to bring the current FENZO code base into a compatibility with the latest mesos lib library. Yeah, it works. Because of thanks to mesos being pretty compatible across versions, and we're not using some of the new features. So it still works. But yeah, that should not be a problem. Thank you. I think that's about all we have time for. Thank you very much. All right. Thank you.


Welcome back everyone, I hope you're all faring well during this extended Twilight Zone episode that we all now know as Everyday Life. Part of what's making this stressful for everyone is not knowing how long it will go on. Nobody seems to know if it's going to go on for another month or another 18 months. One day they're saying 200,000 plus deaths, the next day they're saying 60k or maybe even less. It's really hard to tell how much of this is legitimate and how much of it is politically driven. Part of what makes it hard to determine that fact is the fact that our media is clearly aligned with one of the political parties and is clearly pushing their agenda. This past weekend of reporting underscores this reality with both network and cable news deceptively reporting that the US now has the highest rate of death due to the China virus. And today the United States surpassed Italy as the country with the most deaths. This latest surge pushing the US total beyond hard hit Italy after already overtaking Spain, now the deadliest nation to confirm COVID-19 fatalities. People who trust these hucksters probably watched this and thought to themselves that they were witnessing another Pearl Harbor or a 9-11. That's what the media wants you thinking to yourself.  First off, we don't really know how many people have died in China because China has been lying about this since the beginning. A fact our media mysteriously wants to cover for. Second, the US is the third most populated country in the world. So naturally the raw numbers are going to look bigger than other countries. However, if you break that number down per capita, the US is nowhere near the highest rate of death in the world. According to the Media Research Council, as of Sunday, April 12th, the per capita number of deaths in the US stands at 6.61 deaths per 100,000 residents. In contrast with the UK, where the per capita rate comes to 15.84 and in France where it's 21.48. Both the UK and France are sitting around 10,000 and 14,000 deaths and each of those countries has a population of around 67 million residents. Per capita, Italy, Spain, Switzerland, Belgium and the Netherlands all have much worse rates of death than the US. And good luck finding any stats or charts showing the per capita breakdown by country. I couldn't find a single one or article about that. We'll get right back to exposing this latest media con job, but first I have an important message for all my viewers. The world we live in today is in flux, filled with a flood of information that's often as much gossip as fact. Making it hard to know what the real situation is, making it easy for people to panic and make bad decisions. The only way not to get caught up in that chaos is to have a plan allowing you to avoid dealing with empty store shows, long lines and in the worst case, desperate people. Use today to prepare. A great place to start is storing food in your home. I'm prepared and I ordered even more recently. With this unprecedented emergency, orders are being delayed, sometimes eight weeks or more. I urge you to add your order to mind today. Make action so you're ready for what's coming and save $70 on a two-week emergency food kit. When you go to my special website, preparewithdronetech.com. Those that know what's coming are preparing today. Go to preparewithdronetech.com. That's preparewithdronetech.com. Over at MSNBC, Joy Reid was spreading misinformation as usual, claiming that hundreds of mail carriers have died from the China virus. And one of the groups of people who cannot work from home are people who work in the postal service. 600,000 employees in this country, hundreds of mail carriers have already died delivering our packages and our mail. Wrong. I'm not a highly paid journalist, but I just went on to Google, did a search and found that only 19 mail carriers have died. What else is there to say? She either lied or she has no business reporting on the national airwaves. He brings us to Jake Tappdance over at CNN, who interviewed Dr. Fauci this weekend, but failed to fact check him when he claimed that he was warning Trump about social distancing in February. And something else I just want to point out, check out this headline. Fauci admits earlier COVID-19 mitigation efforts would have saved more American lives. Let me tell you, I watched the whole interview. At no time does Dr. Fauci do that. In fact, he smacks down Tapper and tells him that there's no way that we could know that. In reality, Dr. Fauci was downplaying the virus up until the end of February. If you take a look at where we are right now in the U.S., the U.S. now has 50 times more cases and almost 100 times more fatalities than South Korea. Meanwhile, while the U.S. makes up only about 4.25% of the world's population, the U.S. has 30% of the world's reported coronavirus cases and almost 20% of the reported coronavirus deaths. I just want to stop it here real quick. Tapper's being real deceitful with these numbers that he's presenting. First he uses wrong numbers for the OMG effect of 20,000 dead, then switched to the per capita while comparing the U.S. population to the rest of the world. He could have easily done the same thing, but per country. But he didn't because doing so would have shown that things aren't quite as bad as they seem. Don't get me wrong now, all of those deaths are bad.  But let's put things in perspective here. If he'd have shown each country per capita, it would have shown that the U.S. is nowhere near leading in deaths. Sanjay Gupta said this is all because we got started too late in the U.S.  I'm sorry. I mean, to just say this is all happening because we got started too late. But where we are right now is the result of a number of factors. The size of the country, the heterogeneity of the country. It's, I think it's a little bit unfair to compare us to South Korea. OK, I just want to stop again to point out that Dr. Fauci actually backed up what I just said by pointing out the size differences of the countries. So kudos to him for smacking Tapper down on that. The New York Times reported yesterday that you and other top officials wanted to recommend social and physical distancing guidelines to President Trump as far back as the third week of February. But the administration didn't announce such guidelines to the American public until March 16th, almost a month later. Why do you think lives could have been saved if social distancing, physical distancing, stay at home measures had started third week of February instead of mid-March? You know, Jake, again, it's the what would have, what could have. It's very difficult to go back and say that. As late as February 18th, Dr. Fauci was downplaying this outbreak. In fact, from January to at least the end of February, he was downplaying it. Perhaps that has something to do with why Trump didn't immediately order the nation to socially distance. We've never been through anything like this. It's brand new to everybody. CNN's favorite Botox sponge, Nancy Pelosi, was encouraging people to go out and groups and visit Chinatown, and that was on February 24th. So I can already tell what's going on here. CNN and the rest of the Democrat Party media are trying to set up the next impeachment narrative for Trump. We've seen this playbook before. Back during the Bush administration, the DNC media and the Democrats tried to claim that Trump knew about 9-11, but did nothing to stop it. At the time, polling showed that around 60% of Democrats thought that Bush either knew about 9-11 and did nothing to stop it, or it was actually behind the attack himself. Now they're going to do the exact same thing with Trump, no matter how absurd it is. That's all for this episode. Please hit that like button, share and subscribe. If you enjoy my content and you want to support my mission, please consider subscribing to me on one of these platforms. You can find all the links in the description and pinned comment. Thanks for watching. Keep coming back.


Hi everyone. Happy Labor Day coming at you with 2021 Panini Flawless Baseball a one-boxer random team break number 27 Everyone gets a random team in major league baseball big thanks to the people who bought their spots straight up and Congrats to the people who won spots in those two fillers we did and all 30 teams are in Let's roll it randomized names and teams two into two for the hard way one two three and four Jeremy down to Michael two and a two four times for the teams one two Three and good luck fourth and final time That's four right there. We got the Nats Down to the Tigers All right, Jeremy with the Nationals Nester with the brew crew Aaron with the Red Sox Nester with the Angels Aaron with the Diamondbacks Michael with the Mariners Aaron You got my Dodgers Michael with the Rays Aaron with the A's Nester with the Braves Yon with the Twins Jeremy Port pirates and Marlins Matt with the Rockies Jeff with the Padres and Cardinals Barry with the Blue Jays Matt with the Cubs Michael with the Royals Aaron with the O's Chase with the Rangers Aaron with the Yankees Jeff with the Guardians Jeremy with the Met Michael with the White Sox Sean Healy with the Reds Ryan with the Phillies Jeremy with the Astros Chase with the Giants and Michael with the Detroit Tigers Let's sort alphabetically by team and I'm gonna flip back to the screen in just a second, but trade window is open Here's the fresh case of 2021 flawless baseball right over here. Let's see which briefcase. We're gonna do We'll use this die right here 123 for the top box four five six for the bottom and it's three one two three top box The bottom box will save this is random team 27 will save for random team 28 Which is a which is in the store right now? So it'll be the same sort of vibe. We'll have we'll sell some full spots. We'll do a couple fillers Then we could we can run this back tonight if you want I'll set it right here just in case. Alright, let's flip back over here We're gonna pause the video when we come back We're gonna see if there's any trades and then we'll have the break to ground. I'll be right back All right, welcome back boys and girls No deals were done. So the list remains the same just print it out hot off the presses Jeff with that Last spot mojo with the Cleveland Guardians According to Jaspie legend last spot mojo 70% of the time hits 100% of the time Let's see what we got here. Good luck. So as always we'll do the Do the cards in the slider box first and then we'll do the encased cards Now baseball only has two encased cards. Sometimes we'll get a bonus third Which is usually a good thing because it'll be a bad knob or a No third hit. It'll be a bad knob or like a cleat or something like that I think the auto is on the left side. The gem is on the right side. I'm gonna hide use these blank cards Hide the hits So remember the gems are naturally mined not lab grown if you missed out on this one boys and girls if you're watching live Um There is uh another Briefcase right here in the store jaspie's case breaks.com. Good luck everybody We'll use the blank card with the jaspie sticker on it to Hide the hits up there slow play it a little bit Good luck First out of the gate Is a train whistle out of fives and under get the train whistle two out of five triple relic joey bart Chase with the san francisco giants Chase all aboard the big hit express Nine out of ten mark maguire triple relic Jersey a couple pieces of his lumber m a's edition going to erin dual relic an autograph ryan weathers six out of 25 three color dual relic ryan weathers like he's been having a decent season jeff with the padres Eight out of 15 kyle hendrix premium ink autograph for the cubbies It'll be for a mat mat beat Mickey moniac. Ooh some nice colors in there seven out of 15 for the fillies ryan storm with the fight and fills got brady's singer one out of 20 not a talker not a yeller but a singer That's michael l with can city Well, this flawless looks we got a couple more here. We got dalton varshow Eight out of 15 excellent patch Nice on-card auto erin with the diamond backs The last one here is a three out of five rookie patch and auto kasey myse Former number one overall pick Arm issue this year Got knocked out for the season Probably part of the next but he's a former number one overall pick I just put the sick this in a drawer and check in on how he does when he's when he's back Michael with the tigers and All aboard the big hit express All right, now you're in cased cards here. I think the gem was on the right side Good luck Got some orange here.  What's happening here? We've got a christie matthewson Seven out of ten legends diamond for the old new york baseball Giants That's awesome Now it'll be for chase and on this side the left side and see what we got Good luck everybody. Remember another briefcase in the store. Oh, I thought I saw a rookie card. I think it's landscape mode rookie logo And it is six out of 20 christian patch eight great patch there nice autograph That is braves addition that's going to go to nester And there you go gang love this flawless stuff. The case is closed on break 27 But we got random team 28 sitting in the store. Check it out. Jasper's case breaks.com I'm joe. I'll see you next time for the next baseball break. Bye. Bye


Good afternoon and thank you for joining me for another episode of Kondo Insider. My name is Jane Sugimura and I'm going to be your host for the show today. And I have as my guest battalion chief, Reed Yoshida. Hi, Reed. Hi. Nice to see you. Thank you, Jane. Thank you for joining us. And you know, we've got a very interesting program today. We're going to be updating the fires as safety ordinance of the city and county of Honolulu. And those of you, you know, who have been following this and I'm sure there are a lot of people who are on Kondo boards who know about this because the initial deadline for doing the life safety evaluation, which is part of this ordinance, was May 3rd, 2021. But that deadline got extended, but we'll get to that, you know, during the show, Reed, tell me, you know, what, what, what, why are, you know, with this, this ordinance that we're talking about the fire safety ordinance, why do we have it? It got passed in 2018. Can you give us some background on that? Yeah. So this ordinance came about primarily because in 2017, there was a significant fire on the Marco Polo fire that it went, I think internationally, it made the news. And it was a very tragic event resulting in a bunch of fatalities of personnel and occupants in a high-rise building. And from that, the building wasn't sprinkled at the time and, and there were a few others, other safety concerns, the firefighters were extremely hard as well as all the other first responders. And we were luckily able to put it out, but we, there was a lot of loss and a lot of lessons learned. So this ordinance came about to, in an, you know, in a huge effort to try to not have this happen ever again. And that's, that's the basis for what this sprinkler ordinance is all about. And, and so the fire department was, was, was tasked to lead a task force, right? It was the fire, the former fire chief, Manuel Nevis, who chaired the task force. And Hawaii council was a member, I think we had 17 people on the task force. Some people from the fire department and some from the, from the city and, and we had some consultants and, and I think we, what we were trying to do is brainstorm and, and, and like you said, lessons learned.  And, and like one of the things that I remember the chief talking about were these things called vertical openings. And I didn't know what vertical openings was until I was on the task force. And he, he mentioned that at the Marco Polo, the vertical openings were so large that a person could fit through them. Now, explaining to the listeners why that's so scary to have vertical openings, you know, at a place, you know, at the, at the Marco Polo. And how did that affect the fire? Yeah, so vertical, if we're going to talk specifically first about vertical openings is basically try to imagine if you're barbecuing and you have like a chimney type of thing, the fire often times wants to go up. The heat, the gas, the smoke wants to go up. So if you have a high rise where these units are stacked on top of each other, and it's basically any, any opening or hole that will extend from floor to floor from unit to unit. And, and that fire is looking and smoke is looking for a way to get up and out and continue to grow. So sometimes these holes can be small. Maybe, maybe an example might be a plumbing of where plumbing is at or electrical or sometimes a false ceiling where you have a very large opening. And it's very easy for fire. It's going to want to find more oxygen and fuel and it's going to go up and impact, negatively impact the next person or floor above. So that's a couple of examples of vertical opening and try to picture making a barbecue grill with a chimney and the ones that go from the coals now up the chimney. So it's doing that in a high rise building. There are also, go ahead. No, no, so one of the things that was, was being addressed by this task force was, was like the vertical openings because that's part of the matrix, right? Part of the life safety evaluation. And, and, and so when the licensed professional goes through a building, they're going to look for vertical openings and they're going to basically tell the building, you know, you got vertical openings, you got to close them. And the vertical openings, as I understand it, like when you make a building and you, like you said, you know, there are these pipes and they have to make an opening in the floor so that the pipes can go through the building and then they seal it. But over time, that seal breaks down and now you've got an opening, right, before it was sealed. And so basically now what you have to do when, when the licensed professional goes through your building and says, ah, you got to close your vertical openings, you got to now refill that seal, right? Correct, Gene. Yes. Correct. And sometimes it's sealed and sometimes it needs to be sealed. Yeah. And, and, and another thing with the Marco Polo, there were lots of doors that were opened and there were all these issues with the doors, right? The doors were left open, the unit door, the corridor doors. There were doors with louvers. Tell the listeners why these things are, you know, affect the fire. Thank you, Gene. So yeah, just like the vertical openings, doors that are left open or they don't have the closures where they can blow open from the fire, trying to get from one area to another, that fire is looking for oxygen and is looking for more fuel. So instead of vertically, now you open doors or doors that close or doors that have louvers, now it's horizontally trying to pull through the building and, and it's creating air to allow it to move, not only vertically, not horizontally, but now if the door works, it has a closure. It's rated correctly and it doesn't have louvers. It, it gives us the fire department and the occupants more time, more time to mitigate the fire. Now, ultimately, if there's a sprinkler in there, that's what we want to do is contain it into that one area. Okay. Yeah, talking about sprinklers, okay. And, and, and, you know, with this ordinance, I guess, you know, to, to stay in a nutshell and correct me if I'm wrong, the way the ordinance works is it says that all high rises in Oahu shall be sprinkled except if you are exempt and you're exempt if you are 10 stories or not over 75 feet, or if you have exterior corridors, or if you pass a life safety evaluation. That's basically what it is, right? The Trump is, you got to be sprinkled unless you do these, unless these things exist, right? Thank you, Jane. Yes, you, you are correct. There are a few exceptions in there. And basically it's just like you said. Okay.  I mean, I, I, I don't pretend to know anything about fighting fires. But we were, we were told, the chief said that the whole purpose of us getting together and trying to come up with an ordinance was to protect the people who have to go into these burning buildings and to protect the people who are inside so that they can get out of the buildings, right? That was the whole goal of this, this exercise with all of us meeting together is to find a way to make it safer for the firefighters to fight the fire and to get the people out of the building. That's exactly correct, Jane. You're spot on on that. Okay. So I want to, I wanted to get that clear to the people who are missing because everybody grumbles with, geez, this is so hard. And how come we have to do this? It's going to cost us money. But there was a method to the madness. There was a reason why all of us spent all those hours because the chief said, we got to find a way to make it safer for our firefighters to go into a burning building. And we got to make it safer for the people who are inside to get out. And we got to buy the time. And so so that's why, you know, all these things come into play and like with the doors. And when I remember sitting there and I, you know, when people are talking about door closures and I'm thinking, I don't know what they are. And then they showed it to me and I went home and I really didn't know that I had a door closer on my door. I mean, I lived in my unit for 20 years. I just never looked at the door. And sure, when I open the door, it automatically makes it, it closes it. And it makes it close.  Right. So it's kind of here. But then there's a method to that because of the door has to shut because otherwise it's a fire hazard. Right. Correct. You're correct.  So they open the door and they put the door stop. Those are no notes. Those are supposed to be. That's another thing that came out. Right.  You've got to have metal door closures on the top. And that's so that the doors closed so that the fire cannot spread. Exactly. And, you know, it's it's it's strange because until I sat there, I didn't know these things.  And then there are some and I guess in our building, when we did our life safety evaluation, when they checked the corridor doors and we have 23 floors and luckily out of the quarter doors, only six did not close all the way. Right. So now we have to either adjust the door door closures or replace them so that they close all the way so that they don't leave the door a little bit of jar, right? Because if it leaves, if it doesn't close all the way, that means the air can get through and the fire can get through. Correct. And the same thing with the doors, when when they were talking about raided doors, I went home, I went and asked my site manager, you know, I went to that task.  They have this little metal plate on it. He said, oh, yeah, sure. I said, show me. So he walked me out and sure enough, the plate is on the door.  I mean, I learned more by being on this task force and, you know, walking around my building and and finding out that, yeah, we have fire raided doors and the fire raided doors means that if the door is shut, it will keep the fire in in in closed. Right. It won't for for what, 30 minutes, 40 minutes. And that gives the fire department time to fight the fire and the people in the building to get out. Correct. Right. That's why it's important. And that's why it makes a difference. And that's why, you know, you know, when we when the life safety people, when they did our life safety that and I, we did a memo to all of our unit owners saying we're going to the licensed professionals coming through the building. This is what he's going to be looking for. And this is why he's looking. He's going to check the each door unit to make sure it's fire raided, to make sure it's not a hollow door to make sure there's no louvers, because these things have to if it has louvers, it's not fire raided. It has to be replaced, you know. And so our owners were all informed as to what would happen when the license professional came through and why.  It's like, why us? Why, you know, it's like, why are you doing it to us? I mean, we're not the victims and we don't want to be victims. And that's why everybody should be on board with this program. Yeah, thank you, Jane. You're absolutely correct. The fire department is all for protecting life, minimizing loss of property and minimizing damage to the environment. And really, we want, we don't want any more lives lost to fire. High rise is a very unique type of fire. You have houses, staffed on houses, and it makes, creates a huge challenge.  Right.     And the clock is ticking, clock is ticking. And we have what, 360 buildings in Oahu that we got to get protected. And if they don't have sprinklers and I'm not a big advocate of sprinklers, but, you know, that's why I was on this task force because I wanted to make sure that condo owners had an alternative. And yes, I understand that the alternative is not going to be cheap, but it's cheaper than sprinklers.  I mean, if they want to do sprinklers, that's the trump card. You get the sprinklers and you're fine. But if you don't want to do sprinklers, you've got to, you know, you've got to do the other stuff. You've got to pass a life safety evaluation so that you and your building are going to be safe. Correct, Jane. Yeah, thank you, Jane, on that. Yeah. And then, like you said, you know, with the recent ordinances, there are some things to also help out. Some of it was related to COVID. Yeah.  And I guess what the concern is, and I've told them the way the ordinance is set up, you have what the deadline now to to do your LSE was this month, but that got extended one year. So you've got another year and there's more than half, right? More than half of the buildings in O'ahu have already completed their LSEs. As I understand from the last report that the chief sent to the city council. Yes, Jane, thank you, Jane. Yeah, you're correct. Actually, we just sent out a reminder cards to approximately 130 remaining buildings. Just to kind of let them know, hey, the clock, like you said, is ticking and you reach out to the fire department if you need, have questions, reach out to your design professional. But we're about 130 buildings left. So I think we're making good headway. And it's good that we have that extension now to 2022. Yeah. And, you know, the the concern at the beginning was the cost and my building was it was a 300 unit building. Our life safety evaluation costs is ten thousand dollars. So, you know, to me, I think that, you know, that's reasonable. You know, it's not something, you know, I mean, yeah, ten thousand is not chunk change, but, you know, in on the scale of things, the way we do things in an in a condominium, it's not, you know, it's not that expensive if you have less than 300 units, it's going to be cheaper. And and and we've been flashing the fire department website. Why don't you talk about the fire department website? Because that's got everything in it. I said so many people to the fire department website. You know, when I can't answer questions to go to the website, the matrix is there, the the 17 items that they're going to be checking is there, and you will see that a lot of the stuff you can do yourself. You can get your maintenance people. You can do letters to your owners to start telling them to do these things so that when the license professional comes to the building, you're going to get past his scores. Yeah, thank you, Jane. And I'm really glad that you pointed out the website of the fire department just recently upgraded it. And it's a beautiful website now. It should be pretty easy navigation and really good information. And that website link that is flashing on the screen, it that link will take you straight to the sprinkler area. And we have ordinances up as well as the life safety evaluation and the list like Jane, like you said, the current list, I believe it was just updated in April. That's all on the website. And the website also has all kinds of other information that you know, people can look at as far as what the department does. And more specifically, the Fire Prevention Bureau, what we do. So please, please, I highly encourage all the listeners to take a look at this new website and go to the link and really talk about a lot of things on the sprinkler. The ordinances as well as the list. OK, and you know, one of the one of the deadlines is to do the life safety evaluation. Now that life safety evaluation, the deadline is next year. OK. And so once you get that, once you hit that benchmark and everybody's got their life safety evaluation, then you have, you know, another six years to comply, which means the life safety evaluation. And I don't know of anybody who passed the first time. But, you know, they will tell you things that you have to do. And like I say, when we got our report back, I mean, we've had things like six corridor doors don't close. You know, they don't close all the way so that the closures have to be adjusted. And there are some and we have vertical openings that we have to all address. And we we have, you know, there are some units that didn't have smoke detectors. So we're going to have and we did. We were on a campaign, but like I said, the licensed professional goes and picks random buildings. He happened to pick one of the units that didn't have the smoke detectors. So we got dinged on that.   Somebody told me we could go to Costco and get them for under ten dollars. And so the association has approved, you know, buying the smoke detectors and just making a list of handyman people. If you can't install it yourself, here's a list. Call them, pay them and the association will pay for your smoke detector. You know, but you got to install them. And once we get them all done, then we can have our licensed professional go through and at least check them off. You know, oh, and one of the things that that that we did. And I don't know if the other buildings are aware of it. There is a list of vulnerable people that that the fire department first responders need. And and so and and, you know, it's it's it was like pulling teeth, you know, people are ashamed. They don't want to say it because we posted these notices. I can remember when we first did it several years ago and said, you know, if you're going to need help, you know, exiting the building in case of an emergency, let us know. And and I guess because we didn't explain why we needed it, you know, you didn't get a whole lot of answers. And so then I went around and said, look, if you know somebody who might have trouble getting out of the building, can you give us their contact information because people are not volunteering it? I know there's I know we have people in this building who are going to need assistance. And the reason why you need to make this list is because there's a box in every condominium. Isn't that true? There should be a box in every condominium, or at least the building manager should have an office with a box in it. And first responders will go there if it's not the fire department, it might be the police. It might be the ambulance, but somebody is going to go to that box. They know to go to that box and they will. And that list has got the names, the contact information of the people who might have trouble getting out of the building. That means they have a hearing problem. They have mobility issues. They can't walk or, you know, or for some reason, they just, you know, are unable to quickly move. And so that's where the focus is going to be, right? The first responders will try to help those people. That's why that's why we have that list. And every condominium is supposed to have that list. And there's a special place in the building where that list is kept. And the first responders know where it is. And so that's one of the items that's on the matrix. And and so. And what was new was that we had to send a letter to the fire department, I guess, to say that we would continue to do it.  We have had the list for years, you know, and we updated annually and we updated annually as a matter of force. And if people come to us and say, you know, I, you know, I'm going to need some help if I, if there's an emergency, is there, you know, and so we put them on the list and, you know, and it's when we do our newsletters, we always add that. If you need assistance in getting out of the building in the case of emergency, you've got to tell the management, you know, so that we can make sure that, you know, that information gets to the first responders to so somebody can come and help you. And in and and, you know, we at one time had a fire safety committee and we have, you know, two stairwells and one is open to the air. And so in fact, we checked with one of our local fire guys and it's open to the air. And we said, you know, if we can't get people out of the building because they have mobility, can we at least get them outside through that stairwell that's open to the air? And is that until somebody can come and get them? Is that an accept, you know, like a safe place to move them to? And and and so, you know. But, you know, that's the reason, you know, why, you know, these questions have to be asked and and board members, you know, need to start being proactive in trying to find these people, right? Because it's by the time an emergency hits, it's to figure out, oh, my God, you know, those the next door neighbor, can she make it out? Or what about the guy down the hall?  You have to have this information before an emergency happens. Yeah. Thank you, Jean. Yeah, that is very helpful information. And the key is that it's updated. So, you know, the building manager, the property manager that has it on site that is without is really updated. And when we arrive, we will know where it is.   And, you know, the ordinance talks about an entity called AJH. That's you guys, right? That is us. Yeah. It's the thank you, Jane. That's the authority having jurisdiction and it is often seen in the fire code. You can see it in the city and calling upon a new fire code. And that that that's us. That is us. So that means that if if anybody has a problem, they need to contact you if they have, if they want an extension or any kind of modification or, you know, some leeway in trying to comply with this ordinance, they have to contact your department, right? That's yeah, thank you, Jane. That is correct. You know, if they are showing good fee and, you know, for example, if they have the building permit and the deadline is coming to a really close and they're showing good fee, they send, they either can contact me, send the letter to the fire chief and we'll respond. And case by case, we'll look at it and we understand if they have the building permit pulled and is something is out of their control and they're showing progress, you know, we're going to look at it on a case by case basis. And look at the extension. OK, well, you know, let me get to the new changes. The new changes, like I said, they extended the deadline. So now there's everything's been extended one year. So that means the life safety evaluation you have until next year, May 3, 2022, to complete a life safety evaluation. And then the the six years to comply with the LSE, that's been extended from 2024 to 2025. And then to actually implement the changes. We have 12 years. So that's been extended one year to 20 to 2031, right? Thank you, Jane. So yes, so the submitting the LSE has been extended to May 3, 2022. Passing the LSE, if that is the route chosen, you have to May 3, 2025. And if you choose to sprinkler, that that year went from 12 years to now 13 years, which takes you to 2031. So when and and there also is some another extension. If you choose to sprinkler with, you know, if you're showing good faith again, I believe in the ordinance, it has an additional three years. And that that's specific if you choose to sprinkler. OK, and the new bills to the new changes also requires a licensed professional to submit the LSE report to the fire department, why they weren't allowed, you know, required to do that earlier. But now they have to submit it to you, right? Thank you, Jane. Yes, you are correct. And since this ordinance 21 dash three came out, it's been phenomenal. We've received a whole bunch. So thank you to all anybody listening out there that submitted. Thank you. We've we've been receiving it and we appreciate it. OK, and the final change that we're going to be talking about with changes is that the opt out if they wanted to do the opt out the way it was done before was, you know, you could have an annual meeting and people could vote. But with the pandemic, you can't have annual meetings. And so so the language was changed. So now you could in lieu of a vote, you can do a written consent, which is a ballot, basically, and you can and that means that the association can send a ballot to all the homeowners and they can sign. And so you don't actually have to have an annual meeting and a vote. And that was directly caused by the pandemic and the fact that associations couldn't have their annual meetings. And so we were getting these calls about what do we want to opt out of? We can't do an annual meeting. How do we do this? OK, so now, you know, the city has amended the ordinance so that now they can do a written consent instead of a vote. Thank you, Jane, you're absolutely correct.  And if you're required to submit a vote or make a decision on majority, the sooner, the better, so that you can figure out how how you're going to either pass the LSE or do the sprinkler. So yes, you're correct on that. OK, one question that keeps coming up. And, you know, and it has to do with the building department because, you know, the building department and they're having they have their own troubles, you know, right now and then there's a new director.  You know, so so how do you comply with these deadlines?  I mean, what I mean, and if they if the building comes to you and say, hey, hey, Chief, you know, we applied for a permit, but it's taking what? Well, I mean, it's taking 16 months. We don't have our permit yet. So what what are we going to do? Thank you, Jane. Thank you for bringing that up. There is there first of all, there is something in the ordinance that does the that does address the permits. It's a 90 refers to 90 days and anything beyond that is an extended period of time on top of that. If buildings are showing good faith like we talked about and it's out of their control, you know, just contact the fire department and case by case with a good faith, you know, we'll look at the potential extension to that. So we understand we understand the situation. And as long as they're showing good faith case by case, that will be considered.  And I said, you know, with all due respect, if it's nice that Chief Sox is saying this, but someday he's going to retire and maybe his replacement, you know, won't, won't remember what Chief Sox told us and told you the city council. And, you know, we're going to have this hard time.   And I guess I need for you to emphasize that, you know, to the people who are listening. But thank you, Jane. Yes, Chief Potopoulos, Chief Masuda, they did an outstanding job ensuring that there was continuity in this process. I was involved in it from the from the very beginning with them. I was a captain at the time, but I saw the progress. I met with you back then, as well as all the other stakeholders. And and the public has that can be reassured that it will continue with the continuity was passed down and and the knowledge and the goal moving forward for fire safety in terms of these ordinances will be continued. OK, well, you know, we've run out of time and I'm sure, you know, that, you know, the I'm going to ask the fire department to come back if we have further changes and if there are any other issues. Because, you know, the next deadline is is maybe five or six years away. And I'm sure some will pick up some glitches in the interim and and hopefully you will be around to to come back and answer more questions. I'm definitely will, Jane. And really, thank you for this opportunity to share. And I appreciate you coming and being my guest and answering all of our questions and giving us the information about this new fantastic website, which everybody should go and and try out. And thank you very much for being on the show today and to our listeners. Thank you for tuning in and please check in next week, next Thursday at three o'clock for another episode of Condo and Cider. And that's the YouTube show for people who live and work in condos. Thank you and Mahalo. Thank you. Thanks, Jane.