If you haven't met me, my name is Philippe. I work for Citrix on the Zen server engineering performance team with focus on storage performance. So I've been doing a lot of stuff with storage performance and there's only so much you can talk about in a 20-25 minutes talk. So what I wanted to talk about today is what I've been recently encountering and working with very low latency storage devices, so newer SSDs and things like that. So what happens in terms of the virtualization overhead when you're using this kind of storage? I'll then review very quickly how Block From Block Back, Block Tap QM, Block Tap 3, Qt Desk, etc. works in case you get confused with the terminology and share some of my recent measurements explaining how I've been measuring things today and talking about what we're doing to improve on that. So this is both from a Zen and a Zen server perspective. So one of the things that come across a lot when probably everyone would want to do that is when they first install any kind of Zen environment and get a VM running they would go into DOM 0, so if you're familiar with Zen Center, this is Zen Center on a DOM 0 console and they're going to do some sort of DD and observe what kind of throughput they get. So it's a very simplistic test and here you can see I'm reading at about 118 megabytes a second and then you're going to do the same thing in your VM and in this case again I've got 117 megabytes a second so it's all good, right? I can quit. So it turns out it's not always like that. So what happens when some other people have different types of disks and then in this case you go into DOM 0 and you measure about almost 700 megabytes a second and then you get to do a VM and you measure 300 megabytes a second and of course people are going to argue you have an aggregate, it doesn't work like that, it depends, of course, but as I said, this is one use case. So let me go over very quickly how storage requests transverse the virtualization stack and then discuss some of my measurements. So as you know there are many different ways a user application can do IO. A very simple one is through read and write. So if you have a user process and you have a buffer and you have a file descriptor in this example opened with all direct so it bypasses any caching and you do some read that's going to go into a syscall handler, it's going to bounce around in the kernel for a bit, end up in the block layer and then you're going to have a BIO placed in your request key for the previous device. You kick the driver, the driver passes your requested device and eventually some hard interrupt will complete your request and in the end your buffer has the data. So the most simple case with Zen is work out some of my animations magic, that works. We have a, when my manager saw that he said oh that's why I'm paying you for the PowerPoint animations. What we do here in the, what we call the upstream Zen case or what you get if you just install it and it's, we replace that device driver in the VM with something called block front and we run something called block back in them zero and block back is going to pick up this request from block front and pass them to the block layer and up in your device driver. So it's basically just that. In Zen server we do things a little bit different and if you use QMU or QDisk you might see something similar. We have certain features like thin provisioning and cloning and snapshotting which is supported in the software stack. So what we do is basically store the data in VHD but block back doesn't talk VHD. So we introduced software component called TAPTISC and it got a little bit tricky because we cannot get block layer to talk to a space component like that so what we did at the time and this is just historically done like that was to introduce a new component here called block TAPTU. So block TAPTU provides a block device that block back and talk through the block layer and block TAPTU would talk to TAPTISC and then TAPTISC would complete the request through lib.io. So the data path is a little bit longer, of course there's a little bit of added latency here but we can then work with VHD and do storage migration and things like that using this model. So this has been historically done like that way before people started thinking about SSDs and other concerns with that. So there is a slightly different use case which is the one with QMU QDisk and TAPTISC 3. And what we do there is we get rid of this and we replace TAPTISC with QMU, the only difference here is actually that QMU doesn't really use lib.io, uses POSIX.io which is a little bit different, it's more portable and it has other differences and we get this user process to talk straight to block front through the Grand Dev and the event channel device in order to do the grand mapping and get interrupted and interrupt block from back. So that's about it. So to measure these things what I did was to grab three different types of disks. So the first one you see there is a Dell, it's a Seagate SAS disk, a 15K RPM enterprise class hard drive. The second one is a Dell SSD and the third one is an Intel SSD which is pretty fast. And I grabbed two of each, I created three sets of RAID 0, put them into the same box so I had three different volumes connected through a Perk H700 and I started to measure reading with what I was varying my block sizes so here from one sector all the way to four megabytes in logarithm scale and observing what kind of throughput would I get in megabytes a second so here bigger is better. And what I could see is that while I was growing the block size per request in 232K the throughput was about the same up after which point I kind of reached the maximum throughput that this SAS disk could offer and then you see the throughput doesn't change anymore no matter how much I increase my requests. That's the blue line. So on the green line those were the Dell SSDs, the one in the middle in the picture before. And you see they get faster up to 128K and then they drop. And what happens here is just that the controller, the device driver for that controller actually advertised the maximum request size has been 120K, 128K. So at that point the block layer starts sending one request of 120K and another one which is depending on what I was using here for another 4K and then just splitting requests up. So that configuration was sensitive to this and that is the green line. And on the red line which is the Intel SSDs you would just carry on getting faster. There is a little bit of a bump that are 120K again but less sensitive and then you just carry it on. So this is measured on top of Zen 4.3 on a CentOS 6.4 and the 3.11 kernel. So I'm going to pick two of these which is the blue line with the SAS disks and the red line which is the fast Intel disks and compare them on a virtualized perspective. So if you look at the blue line and then I run a VM. So this was a Debian Weezy VM with all the VCQs pinned so it's a very big box but I kept everything into the same Neumannode and I run my measurements from the guest. What I see is that that's the purple line here. All of them are slower up to just over or just over 60 something maybe just over 100K. At which point the throughput I get in the guest is the same. So this kind of matches what you saw on those first two slides when I was doing DD from Zencent and we measure something with one megabyte block sizes and Domziri measure again in the VM we don't see any overhead. So this is the plot that tells you exactly why. If I add measurements from a disk that has been plowed using block front 3.2.0 so the difference here didn't use the 3.11 because the 3.11 has persistent grants implemented I'll talk about that a little later. So I just wanted to simplify what we would normally see. And it was block back plugged directly to the block layer. So it was what I was describing as the upstream Zen case. If I plug more disks to this VM through Q to tap this to and block tap and through Q disk what we see is that the throughput doesn't really get that far that doesn't really get that high. So we never really match the throughput we were observing either with block back or with the or with bare metal or even from Domziri. There are many reasons for this. There's some CPU overhead here. There's the longer data path. There were some added times. I'll talk about that later as well why this happens. So this is what happens in this configuration using those SAS disks. Now I will show you what happens if this was being measured on top of the Intel SSDs which is the red line now. So you see that block back was sensitive as well to that bump at 120K. But even block back is unable to actually be fast enough to match the SSDs. So if someone actually sets up this configuration or a similar class of a very fast enterprise storage and try block back directly or some user space alternative, they're gonna see a massive performance hit. And I can even flick between these lights. And you can see how the block back in the user space doesn't really get any faster at that point, but the SSDs can just go faster. So the problem now is to understand what actually is going on. Why is it not faster, right? Where are those bottlenecks and what can you do about them? So what I decided to do is stop looking at this in terms of throughput. And throughput, as you know, is just the amount of data it can pass in a fixed amount of time. Now if we invert that, what we get is the amount of time it takes to pass a certain amount of data. And if we're passing just a small amount or a very size of data to the guest and back and not send anything parallel, not break up requests, we can actually measure the time it is taking for the data to travel around and try to work out where things are getting slow. So if I plot a portion of that same graph as before, and here the colors have changed and the scales have changed. So just to show you, I'm just varying in the nearest k up to 128k, measuring at every 4k. And on the y-axis now, I have the latency it takes to serve those requests. So now lower is better. I can see that from dom zero, I can still request that pretty, pretty fast, maybe this was maybe 50 microseconds in the beginning with very small requests and then up to just over 100 microseconds. And then what happens with blockback, you can even see that glitch at 128k in the end, and what's happened with my use of space alternatives. So now we can see, oh, this is how much slower it actually is to serve requests of that particular size. So what we need to try to work out is how much time I'm losing on each one of these stages. What am I doing during those 50 microseconds? And what am I doing on that 3, 400 microseconds that has taken so much longer? So what I did is to start inserting trace points during the path, the code path that serves those requests using our DTSC. So this basically measures a fixed constant with a timestamp counter that is consistent across course. So I can get that from different domains and I have a solid reading on how much time has passed between that particular piece of code being executed. And I observed a few things. So I observed that if you're just passing lots of requests, the first ones you pass are usually slow. So you need to use some sort of technique to trace this in which you can pass lots of requests and see what happens after the hot path is actually warmed up. To do that, I used a trace print K. So I could just put everything into a trace buffer in the kernel and then look in the bugger fast for the actual timestamps that I've read. And then the user space within the application that I was reading from, and if I was using something like TapDisk or BlockDisk or QDisk in the user space, I just made a big static buffer and put all my TSC readings in there. When I was done, I just sent a signal for you to print them out. So I didn't want to be printing them while in the hot path, otherwise I would add overheads to that. And I actually confirmed that with my timestamps in there, I confirmed that to the other measurements that didn't have any timestamps inside, and they were pretty much equivalent. So I knew I was not adding any sort of overhead by measuring this way. And I would run 100 requests through, sequentially reading all of them. And using IFF1, so I was not having requests piping themselves up. I looked at all the times, sorted them out, eliminated the fast and the slowest ones, and just average out the actual time for those middle 80 requests that got served. And I repeated this ten times. And by repeating it ten times, I actually saw some interesting things like sometimes you start this burst of 100 requests. And you notice that blockback has been scheduled in a particular CPU, or a particular vCPU of that range that was pinned. But you observe some difference into the affinity of requests we're going through and from. Of course, when there was anything a little bit weird, I could go back to the raw data for cutting anything out and trying to investigate what was going on. And let me show you where I was putting those traces. So if you remember this path for blockback, I started putting traces everywhere on the path where the request is actually going all the way through. So I can measure things like the latency of the context switching or the latency of the event channel, the latency to schedule, the K thread for blockback, etc. To the point where I send the request to blocklayer. And then I could measure everything else back when the request was actually completing all the way back to my application again. So you can look at the slides later and look at these 12 data points there. And I could actually plot that. So all of these lines correspond to those points you saw before. And what we see here is that this big orange line is the actual time that we spent in the device. And the other lines were spent doing everything else together, requesting there and then back. Now if you want to have a look at the raw data later, I can share that with you. You can go into the, and examine if there's any minimal optimization here that can be done. I think the most important points to raise from there are the actual times that we spend in the grant mapping, and the grant and mapping. Which are the two lines, the brown triangle and the other one with the cross. Second and third to the top one. This now has been measured on 311, but we disabled persistent grants both in blockback and blockfront. So in the conclusion of these slides, I'll talk a little bit more about why we did that. So this shows actually the overhead for that. We know or we believe, as Boris was saying, you don't know anything until you've properly measured it, that there is some sort of contention on the grant table. And if we were actually doing concurrent AO and having many domains hammering them zero with AO requests, this would probably not grow linearly. It would probably go worse a lot more than just that because of locking issues. But we haven't measured that just yet. So what happens when you actually have persistent grants in this case? So that's what I noticed when I actually had persistent grants. There was a lot of two lines before that were the lines for the grant map and the grant map actually dropped down. So they started to be executed really, really fast, even for bigger block sizes. But the time that I spent copying the data from the persistently granted pages was actually pretty high. Now I know it would be better if I actually have a total line to show this, but the sum of these bottom lines is actually not higher than that, it's lower, which means the persistent grant for this use case was actually worse. So for aggregate throughput the persistent grant is good because we eliminate the contention on the grant table, or we believe we're doing that, it is faster Roger when he implemented that, he measured this. Also for the user space alternative, so this is for blockback, the persistent grants also help because the current way we're doing grant mapping and mapping on the grant device is actually slow. Again, something we believe I haven't effectively measured that just yet. So for user space alternatives the persistent grant is very good. Now there might be other things we can do there, I'm going to go to that later. So just to summarize, I just did this measure because this was just something very recently got up streamed to 311 and I wanted to examine that in this fashion. So what I observed is that with the persistent grants we were going to do less flushing because we're not doing as many unmapping. And we believe to have less contention on the grant tables, so concurrently it was probably better. But the problem I see is that currently blockfront will always use the persistently granted pages even if it hasn't negotiated persistent grants for blockback. So we would always copy. So ideally you should support both their paths. I already have a chance to talk to Roger and he agrees with me and this is probably something we're going to be changing soon. So we believe it would be better if administrator could decide which one of these is in my deployment I'm going to use persistent grants or I'm not. It depends on the particular case. So there are a number of things we can do for improving here. So this is the time where we have to start thinking and experimenting with things and people who have ideas should step forward and get involved. Now all of these SSDs and VMEs and whatever, it's pre-new technology. And as I showed you the block-tap stuff we're using, that's probably still from before SSDs. And there are many new aspects changing in storage technology very, very fast. And for the next years we anticipate to be doing maybe a million IOPS with a single stream so devices responding in one microsecond. And we cannot afford to be spending several dozens of microseconds in ground mapping or mapping. We're not really getting them, the cores are not really getting that fast and we need to find new ways of doing that. So some of the ideas that I've been discussing, there's persistent grants. I'm not going to go into detail with all of them, I'm just going to mention some and we can discuss that later. There's persistent grants that we're just talking about. So we know that ground mapping and mapping is expensive, we know there's some condition tables, this is the way of helping that. Another thing that got implemented in 3.11, which I believe is very, very helpful, is indirect AO. So up to 3.10 something, we could only... Each request that would be put in the ring between block from block back could be at most 4K. So the request structure only had 11 segments for pages and we could not address more than that. So if you issued a larger request it would get split up. That also limited the total amount of data it could have in flight because the ring only has 32 slots. So unless you're using multi-page ring or doing some other thing like that you'd be very limited on the amount of requests you can put through. So indirect AO fixed that by having the... the one segment pointing to a page full of segments for other requests you can have very large requests per ring entry. So Malcolm in our sense of engineering team also proposed something where we can avoid doing TLB flushes if we hadn't touched the pages and we realized that in the storage data path we don't really look at the data. So we still do the mapping but if you don't access data we don't need to force a TLB flush. David here, he's been talking about some other ideas for the user space alternatives in which we introduce a page full handler or we don't really need to grab a map in the user space and the kernel, which is what's happening now. There are other ideas such as using separate rings for requests and responses. So imagine if the guest has one ring for putting the requests in and the back end could put the responses in a separate ring. So you would facilitate for example to control how many outstanding requests you have so right now we can only have at most 30 requests because you consume the whole ring and then you need the slots to put the responses in. And if you had different requests you could have different threads in your control domain, in your driver domain coordinating saying we're not going to pick up more than a thousand requests altogether so they could just consume the ring slowly. Or if there is only one VM and you have enough memory for you you could just consume the request ring many times and just place the request. You have separate space to put the responses. This could also possibly help with some caching issues. If you are following what's happening at the block layer there are some people working on a multi-Q approach which is basically they realize that in big new machines you still have one single request queue per device driver. So you put the request in there and if the request is coming from a CPU in a different node there is a very high cost of doing remote access and this is again a very big penalty for very fast storage drivers. So the concepts of having software request queues and need for algorithms like CFQ are being re-think. How are we going to adapt to these new changes? This is probably coming at 3.12 I think. That's it, I think it's just about on time. So thank you and I'll take some questions. Questions? Have you answered everything up front? I think people just want to go to the pub now. Yeah. Well they are waiting for the whisky raffle. So no questions? Okay. Thank you.


How's everybody doing today? I'm your host Rich from RichDVLive. I'm here with two very special guests, Ben Samaru, the CEO of WonderFy Technologies and Mr. Wonderful himself, Kevin O'Leary. How are you gentlemen doing today? Great. Thank you. Thank you for joining us gentlemen. I have a bunch of questions for you guys today. First and foremost, let's talk about WonderFy Technologies. Ben, congratulations on the launch of the IPO. Everybody's talking about WonderFy Technologies on the NeoExchange. Please tell us a little bit about this company and why you're so excited about it. Absolutely. WonderFy really is the proxy for the DeFi space. Our core focus really is product and technology. That's what we've been building for many years in the crypto space, our founding team. Our app, WonderFy, which we'll be releasing in a month or so, is really focused on, let's make DeFi accessible and simple for people. There's huge barriers for people getting into it, but a ton of potential behind the technology. That's really our core focus is the app. That's kind of the first bracket. The second is assets that we hold on our balance sheet. We have select assets that we see long-term value in in the crypto space, obviously, Bitcoin, Ethereum, and then specific DeFi assets that really drive value. They're not speculative assets and we're long on them. This isn't a trading portfolio. They're held in a qualified custodian. We're earning interest on some of the assets through staking and other mechanisms in DeFi. The third part of the WonderFy umbrella really is around strategic consolidation. We're stepping into a market where we're really ready for some consolidation in the crypto space. Our unfair advantage with WonderFy, which really crosses over the product and the consolidation strategy, is we have probably the most valuable currency, which is the power of the crowd and of influencers like Kevin and Josh Richards, who have millions and millions and millions of dedicated followers. They're bought into the WonderFy story, our mission. That really creates some super interesting opportunities for us with getting the product into people's hands and then also with really consolidating some companies that are profitable in the space, but are spending a ton on marketing, really are having trouble around getting their product out. We're really excited about launching on the NEO yesterday and that's an overview of what we're doing here at WonderFy. Congratulations on launching on the NEO. Our community is super excited about WonderFy technologies. Everyone's gobbling it up and buying the stock. Kevin, I have a question for you. You've invested in FTX and Circle, two of the biggest names in crypto and now you're the largest strategic investor in WonderFy. Tell us about your investment. If you think about what I did with Circle and FTX, that was to solve for my operating company compliance issues. I disclosed previously, two months ago, that I had 3% waiting in crypto, primarily in Ethereum and Bitcoin, but I wanted to increase it to 7% by year end, not just in those assets in many different crypto assets. For the operating company level, I have an internal compliance department of external auditors. I have to also report to the regulator because I'm an investor in so many other financial services companies. I don't have an option to be a cowboy here. I can't run around. Think about this. If you're running a billion dollar mandate, you want to put 10% into crypto, you're not going to download an app and put $100 million in it. What you actually need is the infrastructure. You think about a stock or bond. When I buy a stock or bond, there's immediate mark-to-market ability. I can check it new and exactly what my holdings are at every single mandate. I know at the end of the day what the mark-to-market is. The auditors also can look at it on a weekly, daily, monthly, quarterly basis. Of course, we have to prepare our regulatory reports for every jurisdiction we're operating in. In order to do that in crypto, I needed very large infrastructure. I got that in circle for USDC and I certainly got it with FTX. Now, when I thought about what I was my daughter who knows I'm using borrowing and lending strategies to get interest on my crypto called me up and said, look, I'm making nothing on my bank account. Nothing. I'm getting two basis points or something on my savings account. Is there any way I can use your strategy to go and do what you're doing? In the operating company, I said, no, I've got like four people that I've had to hire just to do that and be compliant. That's when I met Ben and realized we can do this for consumers. My daughter and 100 million other people with WonderFi. What she needs is an easy way to do exactly what I've done on my large platform and I'm compliant, but she needs tax reporting. She needs capital gains and loss reports. She has to have those come April 1st for tax filings. What we're building with WonderFi is her solution. She can do exactly what I did. She can start small. She can get some USDC or some dives and stable coins or whatever she wants or whatever she wants and then start lending it out and garner a little interest and learn how it works. That's the whole idea. I feel all my bases are covered. Yes, I'm a strategic investor in circle and FTX, but also now in WonderFi because I need something for my millions of social media followers. That's great. Now, I absolutely love the idea behind WonderFi because I have an accounted index that's out of Calgary. I've had it for years. I got Bitcoin, Ethereum, Ripple, and I'm not getting any rewards. I'm not getting any staking rewards at all. I love what you guys are doing here and I'm going to move all of my assets over and we're going to get our entire community to move all of their assets over to WonderFi. We're really excited about what you guys are doing. Now, in saying that, Ben, you guys have a wonderful team here that you've put together, a very powerful strategic team. Can you talk a little bit about your team that you've put together on WonderFi Technologies? Absolutely. I'll start with the management team, which is our co-founders, so myself, Kong, Kardick, and Dean. Kong, Kardick, and I, we were part of the first coin capital team, which was acquired by Galaxy Digital in 2018. That's one of the bigger names in the space. Really, what we did there was we, again, found a problem to solve, built a product around it and that's what led to that acquisition. We've all been in the crypto space for a long time, which helped us build really good relationships and that's what's allowed us to move so quickly with WonderFi and get people like Kevin involved because we have a track record in the space. We're really proud of what we've done and super excited about Path Forward. And then in terms of our team, we've got an incredible team as well. Our engineering team and product team have built products that have been used by millions and millions of people, like Shopify and HootSuite, and some of the product and engineering team are founders themselves. So they're very entrepreneurial, very involved in the crypto space, so we have a world-class team building the product. And then on our board, it's the CEO, former CEO and co-founder of Hud-8, Sean Clark. Hud-8's biggest Bitcoin miner in North America, listed on the NASDAQ, huge success story, and the CEO of Big Digital, which a lot of people in the US and Canadian markets will be familiar with. They're focused on compliant first crypto and Stephanie Lee's on our board as well, who's a high growth CFO. So we've got a super well-rounded board and then on our strategic investor side, which really is the unfair advantage. Not only were we backed by Argo and Big and these household names in crypto, we're also backed by Sam Menkman Freed and Alameda, which is the biggest name in crypto. Sam, however you want to cut it, what he's built is incredible. So we're backed by Sam, we're backed by Kevin, the biggest name in finance and investing. And then Josh Richards, who I would definitely encourage your audience. If I don't know where the demographic falls with your audience, Rich, but some people, if it's more millennials, might not be as familiar with Josh yet, but he's the voice of Gen Z. He's a strategic advisor to the NHL. He's got a podcast with Dave Portnoy. He's breaking into the millennial crowd as well, but he's got a really unique lens on Gen Z, which is the biggest demographic in the world. And so we've got just a really incredible team of strategic behind us. And again, I just like to say this because I think it's important, especially these days where there's a lot of projects that are being promoted and people get brought on in different ways. We're not paying a dollar for these people. These are people that are invested in our company. And I think that's really important because it is part of our unfair advantage. We love that here at Rich TV Live. We love to really understand the fundamentals of every deal we invest in. Now in saying that one of the deals that we invested in a couple of years ago, one of the hottest IPOs that Kevin has actually famously invested in is Mind Medicine. Mind Med. And our community got in at 30 cents and it was a 10x for our community. A lot of our members are still holding the stock. Now my question for you, Kevin is, is Mind Medicine similar to WonderFi and is WonderFi potentially the next Mind Medicine as far as potential growth? What got me into Mind Med was the idea that the market is so huge for a solution to things like anxiety and opioid addiction. And Mind Med was the first of many companies now that are starting to pursue these medicines going through the trial FDA trial process. But that's right. It's a very binary investment. You kind of, I own stocks in many companies that are in psychedelics because I think at some point we're mostly in stage one and stage two trials, so you've got time to wait. But you want a really broad portfolio of different molecules. Now, the same is true for what's going on in DeFi. The size of that market, its potential, is massive. And I'll just give you a couple of uses because it's a great analogy of drawing. If I could only solve and I'm using, I'm going to be using WonderFi to solve for my, you talked earlier about how your assets are sitting there as property and not getting any, let's call it rent. If you think of Bitcoin as an asset like a building in Boston, well, I get rent off my building in Boston. I get a check every month. I want the same thing to come out of when I loan out my stable coins or my Bitcoin or whatever I'm loaning out. And that's the WonderFi platform that's going to help me do that and provide the reporting I need. But that's just one use. The other use that I think DeFi is going to solve for, and we don't know when yet, is going to be just take FX trading, currency trading. Every time I buy a stock on the domestic exchange in Switzerland or Paris or London or Zurich, I have to pay an FX trader to convert my fiat currency into the Swiss franc or the Euro or the British pound, then buy the stock every time I pay a fee. And that FX trader adds zero value. And I've been doing this for years. I can't wait to eliminate that because one day the regulator in Switzerland will agree with the regulator in New York and say, okay, we can use a DeFi payment system to actually do that trade and not have any fees or 99% less fees. And so those are all the applications coming and those markets are huge. So if you're going to get into DeFi, you get three basic benefits when you buy and become a shareholder of WonderFi. Number one, you're getting a portfolio of crypto assets that we hold on our balance sheet, and we hold them for strategic reasons. So you're getting exposure to multiple assets. Number two, you get a proprietary app that we're building and maintaining for hopefully millions of customers. And number three, and I think this is where it's going to get very interesting, because Josh Richardson and I have millions of followers, we're very good at reducing customer acquisition costs for any company. So we're going to try and find companies that have assets we would like to own and buy them and use the WonderFi platform to do that and help those shareholders reduce their customer acquisition costs. So I really like what we're setting up here. I think the analogy of the giant market that my men's trying to address and the giant market that WonderFi is trying to address makes a lot of sense. And I think it's one of the reasons I'm still a huge shareholder in my men, and I'm a large shareholder in WonderFi as well, because I think they're great strategic investments. That's great. I'm super excited to continue to watch this evolution, because this is just the beginning. So to think about what the potential is, it's kind of like getting invested in TD Bank when it first started. I mean, it's super exciting when you think about the potential, a digital bank that's giving you rewards, it's going to put a lot of pressure on traditional banks. So this is the future, and we love WonderFi technologies here at Rich TV Live. So my next question for Ben is Sam Bankman-Free. Wow. That is like the biggest name in crypto. What is his involvement in WonderFi? And does this align WonderFi with FTX? So I mean, I can talk about, yeah, so Sam through Alameda, which is a trading firm that's associated with FTX is invested in WonderFi. So we got introduced through Kevin, you know, and amazing, you know, have had some amazing conversations with Sam and his team. They are doing incredible things over at FTX. And so, you know, I think we're really aligned on mission. I think we're exploring opportunities there with them. And Kevin can speak to this a little bit more. Some of the viewers might be aware that Kevin is an investor in FTX and, you know, a sponsor promoter of FTX. So we're aligned on many different levels with them. And to me, it's if there's one name person company that you want to get aligned with in the crypto space, it's Sam and FTX. That would be, you know, my pick hands down every time.  And then now it's about, you know, exploring the opportunities that we have with them going forward. Ben, I got one more question. What milestones can our viewers expect in the near future? So we're focused on, you know, heads down on the app. So that will be, you know, a big catalyst for us getting that out in the market. It's thousands and thousands of users that are waiting to use it. And a lot of them we're interacting with and doing testing with. So we're super excited about that. There's nothing like it on the market. It's all around accessibility. Like this is a space where it estranges a lot of people and a lot of users. And so we're, and we've been in it for a long time. We've seen the cycles. So this is just about like defies about democratizing finance, but nobody can understand it or use it. So let's solve that problem. So that's going to be a big catalyst for us. And like I said, I think the space is ripe for consolidation. I'll maybe just quickly touch on, because I know there's a lot of conversation around, especially for your viewers in Canada. I know you have a mixed audience, but for the Canadian viewers, there's, you know, a big push on regulation in Canada. And we've seen the first licenses get issued for centralized crypto exchanges. My experience background as a securities lawyer working specifically around licensing fintech companies in the crypto space, like going back a few years, the one big problem with regulation in Canada is as soon as a license gets issued for something new, like a, you know, whether it's a crypto investment fund or a, you know, an exchange, companies spend many, many years and hundreds of thousands of dollars getting that first license. And as soon as that's out, you're going to see many more licenses come out soon, because they've done all the hard work and heavy lifting with the regulators. So we've got, you know, 15 or 20 centralized exchanges in Canada. So consolidation is coming, licenses are coming. And our view, again, on the accessibility pieces, not only do we need to have a decentralized app where people can own and control their own assets and are in yield on it, which is our app, but we need to have ways to get people into crypto. And so centralized exchanges are a part of that, part of the ecosystem. So we're, you know, we're exploring some consolidation opportunities that I think we're in such a good position for because of our backing and then also just timing in the market. Fantastic. One last question for Mr. Wonderful, or should I say Mr. Wonderfie? I think that that's a genius name, Wonderfie. Obviously, the origin is for Mr. Wonderful. So one last question for you, Mr. Wonderfie. I've heard you're very particular, and I know from watching you, you're very particular with what you invested. So when you made this decision in the crypto space to get into Wonderfie, you had to obviously put a lot of due diligence and a lot of time into it. Can you talk a little bit about some of your other investments you've made in the crypto currency space? Sure. You know, when I get involved in a company and do something like put my name on it, Wonderfie, for example, let's be transparent. I'm ripping off Richard Branson's Virgin strategy, and I'm happy to do it. I know Richard, but I think it's a brilliant marketing strategy. So you'll see many other companies I invest in adopt that nomenclature because it fits into my portfolio. But I always eat my own cooking. I don't invest in things that I don't use. And so the best way to be an investor is to understand the product as a user. And so for me, you know, when I talk about FTX, I'm an investor, but I'm also a user of the platform, the same with Circle. I use it. The same thing is going to happen when that app launches in, you know, less than 30 days here. I wonder if my family is going to use it because I've got lots of kids that want to be able to do the same thing I'm doing on an operating company level, but they need compliance too. And so my thinking is it's always invest in what you use. And then you'll have the knowledge of what the person you're serving is using. And that's pretty well been in and everything I've got. I mean, my goodness, I look at my portfolio of private companies and venture investments. I have all these products around me because I use them, you know, whatever it is, from food products to wireless charging and all of the same thing. But when it comes to crypto, my biggest concern right across the board is, am I compliant? Am I doing this in a way that does not change my compliance platform? Because I have to be compliant given all the other investments I have in services, financial services that have to be compliant too. It's that simple. And, you know, I love what WonderFi is doing in terms of the reporting. Yes, you can, you know, move your crypto in there, but also we'll give you the right reports to become tax time. You're compliant. You know exactly what you made or lost and you're able to report it to the regulator. Gentlemen, thank you so much for joining us here today on Rich DV Live. Congratulations on the IPO, WonderFi technologies, and you defy decentralized finance stock that you guys can buy. Guys, if you like this video, please smash the like button, comment down below, share the video everywhere and subscribe. Thank you for joining us, gentlemen. I must just say before we leave that Rich DV Live is strictly for information and education purposes. Please do your due diligence, do your research before you invest in anything that we talk about or discuss here on Rich DV Live. In saying that, I think WonderFi technologies is a great opportunity for investors to get into decentralized finance early before it explodes. And I believe it will. Thank you guys for watching. If you're not winning, you're not watching. This is Rich from Rich DV Live saying, have a nice day everybody, and thank you for joining us, gentlemen.


YouTube launched end screens for all today to use them simply go to your end screen and annotations There's a new tab here. You cannot use it together with annotations. You first have to unpublish any existing annotations to use end screens It's only available for the last 20 seconds of your video. You can't add them before 20 seconds they work on mobile and desktop not just desktop like annotations only work on desktop And let me show you exactly how they look. Thank you for watching this video to get more George Click that subscribe button right there. It's a new end screen. So you can subscribe to Freedom Central home of the George show also click that to see the freedom family plus one video and click that video to see the exciting 60 million cash injection


Super stars man, what happened? Okay, so he tried to take credit for all the number one recruiting class stuff. We know what your business card says. So, kind of have a good career for the pokes. You get back into this coaching thing, you run in the club a little bit. Start having kids and you have more kids. And then that's what I was just asking you about. Like, how much are you spreading yourself then right now? So, talk a little bit about coming out of college and then the adjustment to where you're at now. Well, right now I enjoy the road trips and I get a little more sleep. Get sleep in, sleep through the night, undisturbed. Now I finished up with Perry 2014. We wrestled freestyle, I coached kids club a few years and she was just my third year I think as a recruiting coordinator. It's just kind of do as needed and do as I'm told. So, number one recruiting class in the country, like, I've seen some amazing recruiting classes. You guys just knocked it out of the park. Talk about the level of effort that went into that. Anybody that doesn't recruit in college or closely related or connected to it doesn't realize the time and effort and the strategy that goes into getting one kid, let alone as many kids as y'all got this year. Well, we're fortunate. We had a lot of relationships with our recruits through, you know, through camps or through our careers, you know, and it's a group effort. We have our full staff on board 100% of time and, you know, just stay after it. Talk about coming through the Oklahoma State program and then staying a part of it.  Talk about what being able to stay a part of that. I don't know if I can say the right words for it. It's special. It's special to me. You know, I met my wife in Stillwater. It'd be really hard to peel us away from the program and the community. We're both really invested and really rooted down in Stillwater.


Welcome back to our meds smarter lecture series where we're taking a smarter approach to preparing future physician Before we get started if you'll take just a quick minute and click that like button and also Subscribe and turn the bell on so that you'll be notified when we post new videos Let's talk about that final lactose fermenting enteric bacteria, which is club Cella Remember club Cella once again is a gram negative rod Most of the time club Cella presents itself in patients who are diabetics or alcoholics specifically alcoholics if you think they Become drunk and they will vomit and they can actually aspirate some of that GI content into their lungs so the intestinal floor gets up into the lungs causing a Lobular pneumonia and those type of patients where they aspirate that Gastric contents there with club Cella. It is a very mucoid colony that we see with abundant polysaccharide capsules One of the most common things that you're going to see Associated with club Cella is a dark red or current jelly sputum This to me is a good buzzword for club Cella because You only see a current jelly sputum associated with club Cella if you don't know what current jelly is This is a good picture of a current jelly It's just that really dark red almost bloody Color to the sputum. It's not blood. That's something that's important to distinguish here This is not blood in the sputum. This is just the club Cella causing the sputum to turn that dark red color Club Cella is a very common cause of nosocomial uti's or uti's that are found in the hospital setting and It is associated with multi-drug resistance occurring So let's talk about the A, B, C, D, E's of club Cella So another good mnemonic here to help you remember A, B, C, D, E with club Cella So A is your aspiration mnemonia B is the abscesses in the lungs and the liver C we talked about that current jelly sputum D often seen in diabetics all of this can be associated with that aspiration mnemonia and Then E is ethanol abuse, which we talked about all goes together up with the aspiration mnemonia Let's continue on and discuss Campylobacter de juni. Campylobacter de juni is a gram-negative organism and it's actually got a comma or an S shape to it with polar flagella and you can see here in the scanning electron microscopic view that Kind of the curly-q look here to the campylobacter de juni There are polar flagella associated with it, which you can't really see but they'll be coming off of the ends here Campylobacter is oxidase positive and it grows around the 42 degrees Celsius range So it likes a really warm environment. Remember our body temperatures around the 37 degrees Celsius range So we're talking about a higher Temperature than our normal body temperature.  So person-to-person contact or ingestion of contaminated products like poultry meat that are all undercooked or unpasteurized milk. So if we Heat up that milk and we pasteurize it that will help kill off the campylobacter de juni that could be present there However, if it's unpasteurized, that's how it can be Transmitted. You can also have a transmission from contact with an infected animal so it's not just through a fecal oral route if there is a Potential contact with the animal that does maybe have the fecal contents present on the skin and then it gets into your body It is associated with a potential onset of Guillaume-Barre syndrome as well as reactive arthritis So that is another important thing to note of what you could see in a clinical presentation with campylobacter de juni If you found this material helpful for your studying, please like and consider subscribing to the channel Also share this video so that more people can benefit from it like you have


punch out pitches that he had a couple left jabs a left hook around house also had seven cutters for change ups and the one slider so we'll talk about that change of more in just a minute but first let's hear from Cece about his outing. Cece it's been a rough week for Sonny Gray do you like the fact that he was able to go out there tonight put up zeros for you? Yeah that was huge man I think everybody in here is fired up for Sonny the way he pitched the night was huge for us picking us up and like you said it's been a rough week for him to come back and perform like that is huge. The other day you told me you wanted to try to be aggressive in this strike zone early tonight did you feel like you did a much better job at that?  Do you think you were able to to get so many strikeouts tonight? I think just just just that just being aggressive and Higgy was keeping my balance and you know they were they came out swinging early so it made it easier. And just said he felt like the command was much different tonight did you feel a lot better on the ground? Just getting back there you know still still a little more erratic than I wanted to be you know walking the lefty twice but you know I'm just working. You guys had a really tough stretch and now come back and win two in a row after leaving Boston what's that say about you guys? Well it's a tough team you know it's a team that's gonna give up you know we all got each other's back we know what we're trying to play for and we got one goal that's to get to the playoffs. Why is everyone so fired up for Sonny is it just the way a veteran guy like that kind of respond to do you know get take out of the rotation? Yeah everything he's got a rough week you know I mean I need to explain it you know so I think you know like I said we all pull for each other we got fired up for him so it was good to see him do well. Do you see him seat down after you told him about that? No he wasn't I mean but everything else you know so it was just it's a lot of stuff going on so I mean he took that like a professional I think handled that well and we know he came out today and performed for us good.


Alvin Plantinger is a leading American philosopher from the University of Notre Dame, where he is something of an institution having been there since 1982. He is especially well known for his work in the philosophy of religion, and it's fair to say that Plantinger is one of the key reasons why we are experiencing a renaissance of interest in a philosophical defence of Christianity. His argument, made in the 1970s, that established that there is no logical inconsistency in believing in an all-powerful, loving God, despite the reality of suffering, was something of a turning point in philosophy. Plantinger has written numerous books and people write books about him and his work. I was fortunate enough to meet him at Notre Dame, where we talked about God, Richard Dawkins and personal faith. Do you see this as a last gasp of intellectual scepticism, or is it the renaissance of unbelief? I don't think it's the last gasp of anything. Unbelief has been with us since the days of the Old Testament. The psalmist says, the fool hath said in his heart there is no God. So apparently there was atheism then, and there has been atheism, I guess, ever since. Of course it rises and falls, and more or fewer people are involved in it, and it's different in different parts of the world. So I don't think it's the last gasp of anything. I don't know if it's much of a renewal of anything either. It seems to me that current versions of atheism allow the four horsemen of atheism, Dennett and Dawkins and Pitchens and what? And Harris. And Sam Harris. It seems to me their arguments are somewhat inferior to those of atheists maybe 50, 60 years ago. You've argued that naturalism cannot be rationally believed, a novel argument, I guess, to Sam. Why can't it?  You'll think human beings are material objects, that there isn't any immaterial soul or self or person or ego. And you'll think that a belief is something like a structure of neurons in your nervous system or in the brain and the like, which will have two kinds of properties. The belief will have neurophysiological properties and in virtue of having those it can cause behavior of various kinds. But the belief will also have a content property, it'll be the belief that P for some proposition P. If you accept naturalism and materialism, that combination, then it seems to me you'll have to take it for any particular belief, the probability that it's true is about a half, it could as likely be true as false. All you really know is that the creatures in question have evolved so that they act adaptively, they act behavior-adaptively, but it doesn't matter what the beliefs, what beliefs they've got are. And if that's the case, then the probability that one's beliefs are reliable will be low. Given naturalism and evolution, that probability is low. So there's a sense of not being able to trust your own cognitive thoughts. Yeah, your own cognitive faculties, right. But some might say, well, why should I trust my cognitive faculties that point me towards belief as well?  If you're not like that, if you just, like everybody, just take it for granted that your faculties are reliable, that seems to be perfectly sensible. But if you combine that with accepting naturalism and evolution, then that combination isn't sensible. Well, I've got to be able to point out, instead of saying, OK, let me find the evidence, say, well, hold on, evidence assumes logic. That's correct. And logic is only consistent with the God of the Bible. That's right. Or, hey, give me proof of, hold it, proof assumes logic. And logic is only consistent with the God of the Bible. Well, you see, science is their God in this situation, yet they cannot account for the fundamental assumption of science. Now, I'm going to ask you to put your thinking caps on for a minute here.


What if we could go on? Hold the light a little longer. What if your parents could grow healthier and stay? What if all the knowledge and potential you'd gained over your life wasn't simply lost? That was the beginning of the mission video for the newly launched Jellyfish Dow, a decentralized autonomous organization focused on accelerating the development of health span and lifespan extending technologies. There are numerous dows already working in the longevity in healthcare space doing some very interesting work, including Vita Dow, Cure Dow, Longevity Dow, Athena Dow, and more, but Jellyfish is taking a very different approach. They are seeking to fund longevity focused media, including nonfiction and fiction films and videos, podcasts, games, and more. To tell you why, here are clips from their video featuring Lifespan.io's Tim Moppen and Keith Camido, who are also core members of the Jellyfish team. The problem we're tackling at Jellyfish Dow is how to get the public to be more on board with longevity at large and how to communicate these ideas in a positive light. Our mission is to tell stories and use the power of cinema to get people to rethink aging and many of the associated negative concerns with longevity, to which cinema and story are uniquely positioned to do. Greater public acceptance would move the science faster and ultimately more quickly reduce suffering and save more lives. One of the non-obvious things that I think actually holds back the pace of research is not seeing the value of public engagement initiatives and how that has a force-multiplying effect. So even if all you cared about was just dollars going into research, I think funding media projects that get the public excited, informed, and engaged on this topic is a huge force multiplier and that's one of the reasons why I'm choosing to spend some of my time working with Jellyfish Dow. In addition to spreading the message of longevity through impactful media, members of the Jellyfish community could actually be able to influence the production of these works, taking a sort of producer role to help make decisions and even be featured in the content. Not only that, but they are discussing exciting opportunities with exclusive and original NFTs, possibly even linked to and impacted by the very same breakthrough work they go to fund. So who is this community for? Madalina Ion explains more. We're bringing together a community of longevity advocates, filmmakers, entrepreneurs, and wallbreakers. I'm in the film industry for almost a decade. I don't have a favorite longevity movie yet because we are about to make one. There are three initial feature films currently slated for Jellyfish support. They include a full-length adaptation of Tim Moppen's award-winning short film The Last Generation to Die, Gallia Barcol's documentary Ageless, and the film Madalina just referenced there called Genethic. So how does this all work? Well the good news is that's still being decided and they are actively looking to grow the community, so you have an opportunity to get in early and make a real difference here. If this sounds at all interesting to you, please visit the Jellyfish Dao website at jellyfish.foundation. Once there you can join the team, including me, on Discord. Big things are happening and we want you to be involved. Please share this video to let others know about it as well, and help us support longevity for all. I'm Ryan O'Shea and we'll see you next time on Lifespan News.


Ciao, mi amo Gilbaros, you no parli italiano Sorry, oh una oltra birra per favore the important things to say right So I am in the cloud business unit. I'm a partner product manager and that means I work with partners customers We call it herding cats. I help Integrations come together and in particular operators have opened my latest focus So you've heard a lot about operators in the last few hours Sort of a high-level. I'm gonna dig a little deeper into operators today and Tell you why you should care Why it's important and what you can get out of them We're also gonna talk about Best practices and really what we've learned in the past two years roughly that we've been doing operators and What we've sort of created to help you get there. So we're really gaining momentum a Lot of open-source projects are using operators as the de facto way of deploying on Kubernetes and on OpenShift Nowadays if you look on operator hub You can see a lot of the projects that you use are already there and there's quite a significant backlog But the team I'm on is working on on getting new operators for for new open-source products added to operate a hub But what we're seeing also is that ISV's are Really looking also at operators as for their commercial products for their enterprise Distributions as the way to deploy on OpenShift. So I'm going to assume that you have some experience with operators You've been here for a couple of hours. That's sufficient experience. We'll we'll dig into that a little more And we're assuming of course you have some experience with Kubernetes and OpenShift So let's add to that operators are Procedural best practices they take what's in the minds of Your admins your developers on how to life cycle your application how to do everything from day one deploy the application install it to Fun stuff like metrics like health checks Like auto tuning day one is Fairly well understood right there. Everybody has a script to install their app. Everybody has an Installation tool. That's easy day two is difficult, right? How do you make sure that? You can scale when scaling time When scaling time happens How would you detect that you need to scale? How do you detect that there's something wrong with the health of your app? and Act on that without having to rely on the one Admin the one the one person who deployed it who remembers how oh you have to do it like this otherwise this breaks So the idea is you have Your subject matter experts create the logic for how to do these things and put them in the operator Um Very quickly on how it works. There's a custom resource Which is effectively a Kubernetes controller Kubernetes is watching the the custom resource and the configuration and basically looping on making sure that the Operator and the app are in the Situation that you want them to be right making sure there's enough enough Resources making sure that you know everything is where it's supposed to be But more importantly why why should you care and I mentioned that it's automating Things that are in people's heads That you don't want to get that pager in the middle of you know Saturday night So make it so that we can we can do this and and the day two stuff that I mentioned is the complicated stuff, right? Resizing isn't just scaling resizing is I have to add stuff to load balancers I have to talk about quorum I have to decide where to scale something to is it going to be in this data center Is it on this server? Is it over there? Does it have to be in Asia Pacific? Does it have to be in? The US so there's a lot more to resize than just Add one more instance and you can do that with operators Same thing for upgrades right up upgrades tend to be complicated. You tend to worry about them, but if you codify all of that in your operator It simplifies it and I'll talk in more detail about that as we go reconfiguring or configuring your app a lot of times there are 500,000 possible Tunables configuration options, but you know you really only want your app or your users to change five of those Right, you don't want them to change every other little thing that's going to break something else You only want them to change a few of those settings So you can make it so that your operator Configuration options only include the ones that you want your users to change Backups backup sounds simple until you start talking about backing up databases or stateful data So you can prepare your environment for backup with with your operator And we talked already about healing and and what that means and you know detecting that something is not in the right state And defining what the right states are But it's it's it's more complex than someone that's looking at the dashboard and saying oh this is orange now What do I do? Well? You can make your operator Know what a bad state is know to set it orange and then know how to fix that Is it are you running out of resources? You need to move workloads around things like that? but Let's get into a little bit more of What makes a good operator right? What are the best practices? Those are scenarios or situations in which an operator would be useful, but let's Where can we what are things that we have to do to make this better? So this is Not as bad of an eye chart as Brian's initial one But let's talk about Some of these so this is for the development side. Do I have a pointer? I do excellent I'll try not to blind anybody So this is for the development side of your operator, right? So the if there's one thing that you should leave with here today is Operator should do one thing and do it well Don't create an operator that deploys your entire stack create an operator that does That one part of the app, you know deploys your app and has dependencies, right? So your operator could say for me to deploy this web front end. I need a database. I need You know these three other things But have OLM the operator lifecycle manager handle those dependencies because you don't want to own The operator for all of these other apps all of these other open source projects, which aren't your responsibility, right? those those should be handled by the subject matter experts of those operators Which I think is the first two bullets there Use use an SDK the operator SDK already creates all of the scaffolding like all of the Reusable reusable code that's necessary to make an operator work is already provided for you So using an SDK in the end. I'm gonna have some links to a lot of the documentation on this but more importantly also a link to the learn.openshift.org page, which Walks you through creating an operator It's it's how I learned to do operators a year ago is you just click the learn button and it pops up An environment for you and it pops up the step by step. This is how you create an operator And of course it uses the operator SDK, which we'll talk about a little more Don't hard code things don't hard code namespaces you'd be surprised how often this happens And there's a collision out there waiting to happen. Not all of your environments are gonna look the same And I think lastly on this one APIs have a tendency of sticking around for way longer than we expect So version them properly Have different versions for your operators make sure that they make sense and there's there are communities guidelines and just simver guidelines for how to do that so running running operators on clusters The the The scaffolding the framework is already set up so that you don't need to run your operators roots And I know you're thinking oh no my my specific scenario requires my operator to run his roots It probably doesn't Talk to us about that. We're happy to help. There's there's a whole team of us that Help people with their operators help them develop their operators help them troubleshoot their operators and We've created this framework so that things that usually would need to be run as roots are Handled by the framework so your operator itself doesn't have to write it. You don't need to handle all those privileges that Could cause the issues in the future. So things like CRDs get registered by OLM. So you don't need to do it yourself. So you don't need the provisions for that Writing meaningful status information is Surprisingly a problem that we bump into fairly often. So the one of the groups I'm in Validates and tests and provides feedback on operators that show up in our GitHub repository for operator hub. So I look at a lot of operators During the day and I review them and test them and one of the big things when I'm testing an operator is I don't know That much about your app. I read the description I read a paragraph about your app and I'm trying to deploy your operator and The first thing that I look for when it doesn't look like this installed, right? It doesn't look like this operator is working is what are the what are the stat? What's the status codes that I'm seeing like what are the status messages? Is it telling me that it broke? Is it telling me anything useful about how it broke? and Think of think of me as a user, right? Like I'm a good example of a person in your organization or a person out on the web who Is interested in deploying your app is interested in using your operator, but doesn't know as much as you do about it so Tell me as much as possible in those error messages in those status codes And there's proper places to put them in the in the custom resource object, etc We'll talk about updating But the key thing This this is not the company line. This is my line the key thing for operators for me is One operator one app version So don't have an operator version deploy eight different versions of your app. I'll talk about that more later but more importantly an operator version that should be able to understand how the n-1 version of that operator works and Update that so When you in you know when you develop version You know 1.1 of your operator it gets installed on the system It's going to be working with an existing version of your app and it needs to be able to update that So that's the one thing that you should focus on is that logic needs to go from n-1 to n Don't think of n-2 n-3-4 because we're just going to do it incrementally Don't deploy other operators. I talked about dependencies already use The operator life cycle manager is going to handle dependencies for you so easy Ah Okay, so should always be able to play and come up without user input. So that's another Piece of feedback that I have from Installing you know a dozen or hundreds of operators over the last year is I Don't always know What all the possible tunables are I don't know what the required Configuration options are so when I install an operator it should it When I subscribe to an operator it should install the most basic version of the app with the most Commonly used configuration settings so the app should come up At that point I should go in there and configure it and the operator will then configure the app But it's better for when you deploy an operator to your cluster For it to come up with a version of the app then for it to immediately error out and say you didn't configure blah blah blah You know just have it install like a basic, you know This app can't talk to anybody But it's up and it and it works because then you give that feedback to the user that oh, okay? Everything is good. It's working. I just now need to go and configure it All right, so how do we do this Hopefully you memorize the previous two slides. There is a quiz at the end a test And that will define how many beers you get at the end of the day is how well you score on the Twitter so We'll get there So the operator framework so we've We're aware that there's a lot of best practices that there's a lot of Things that we're telling you you should do it like this. You should do it like that. You shouldn't do this so we've tried to Sort of codify all of this into a framework, right? Like the operator mentality is like put the logic in something so that you don't have to repeat it And we've created some tooling so Three big parts of this is the operator SDK, which I mentioned before It basically creates all that framework for the operator so that when you're writing your operator You really just having to focus on Writing the logic necessary to get that up, you know to get that app deployed, right? You're not worried about to the controller stuff. You're not worried about the resource, you know, like you're We're trying to make it as simple as possible the operator lifecycle manager is What's running on the cluster which handles the the catalog it handles providing access to the operators to the users and also It's it's it's what's taking care of the lifecycle of the operator, right? We've talked about metering a good bit already, so I'm not gonna go into that but you know as as you expect Metering works for operators as well on a per name space basis, etc. etc. So We're gonna go through a couple of sort of a step-by-step scenario on how this works I usually call this person Jane, but I think Julia would be better Okay, so Julia the developer Uses the operator SDK to create a new operator for her app You know the operator SDK does all the scaffolding and she adds the custom logic, right? She adds the how do I actually deploy this app and now she has an operator Easy enough. She gets to focus on the custom logic Taking a step back.  So phase one and two of course are the most common basic install, right? You can you can install your app and you can upgrade it from you know version one to version two or whatever and you'll see that there's Three different options for how you're going to write your operator helm charts, of course a lot of you already have them But they're somewhat limited in that they can really only handle Install and upgrades the we'll get into a little bit more detail on those But the cool stuff is over at the end over here, right? So we can handle scaling auto-tuning detection of issues Scheduling, you know like all of the more complex stuff is also doable over here But you need to use either ansible or Golang or something like that The cool thing about doing this with helm is if you already have the helm charts The SDK can basically just take those and run with it It's it's very little very low barrier to entry. Of course you're it's a good start But you're limiting yourself a little bit on on how much functionality you get If you use ansible, it's fairly similar you need to be able to use the ansible Kubernetes modules, but otherwise it's just ansible, which you already know and the operators to cake and take your ansible playbooks and and run with them with some adjustment, but if you really want the full breadth of What you can do with operators Write it and go and you'll go from you'll go from there while that was terrible But yeah, so three options on how you can get her up your operator written Okay, so I believe this was Joe before is when I do when I do this in the US so Joe will be Okay, so Marco, if I roll the R Marco, okay So Marco will take Julia's operator He's gonna add some metadata and package it up and then Add the operator into the life cycle manager, right? So the metadata is just things like what kinds of permissions our users are gonna have Which kinds of users have different permissions, you know the the RBAC stuff And once it's in the life cycle manager the user who will name later Can then see that operator, you know look at the packages things like that This is I think what I mentioned this before right so operators are really first-class citizens Which means they can do things via OLM that require escalated privileges without having those privileges and OLM really sort of manages these these operator components for you So you don't have to worry about doing a lot of that life cycle stuff. You don't have to worry about pre-registering CRDs You don't have to worry about Setting the actual role-bidings. You don't have to worry about setting role-based access control or namespaces or any of that so Operator life cycle manager really sort of helps set the system up and get things going but Talking about OLM and the life cycle so the way this works is we you subscribe to the operator, right? So the user is subscribing to the operator that You know was in the catalog right Marco put the operator in the in the OLM catalog then the user What did I call the user? Luca Luca is the user Luca subscribes to the operator on his system and the operator gets you know sort of life cycles Inversioned as as it goes right so whenever a new version of the operator gets put in the in the life cycle manager The cluster updates it the OLM updates it on the system. So if we take this a step further I Lost an app off the end of the screen if we take this a step further. We're talking about You know operator version 1.12 being you know deploying your app version 3 and 1.13 deploying your app version 3.1 and etc So this operator knows how to update from this one to this one Easy right which means this operator knows how to update of this version of the app wait this version of the app to this version of the app and Not necessarily previous versions. It doesn't have to do that Because that's too complex why you know why make your life difficult. Oh, I make your life difficult Of course you can we'll let you do that You know, I may get annoyed when I see that in the the operator when I'm reviewing it But yeah, okay, they wanted to do that go ahead And how you do this is basically just set the configuration option in your in your resource and say Deploy this version and then if you want to update it you would just change the resource to okay Deploy the next version and handle the updates. This seems complex to me It's not You're welcome to do it, but do that instead It's so much easier for you to keep track of your app versions by your operator versions You know both will be supported we're happy with you, but but remember In minus one to end Keeps life easy. All right, you've seen the slide before William stole it from me So Dependencies right so we've talked about having your operator do one thing keep it simple do one thing well and that means Your operator is just gonna say I require Yeager or I require cockroach to be and OLM is going to then go and install those for you. So don't write Your own version of the operator for Yeager They there's already a Yeager operator use it life cycle manager will take care of that for you Here we go Julia Marco and Luca all right so The operators made it to here and now Luca says oh, okay. I want that app so Let's Subscribe to that operator channel You know I'm gonna say which namespace I want it to be deployed on and then suddenly there's an operator Instance and the operator creates a managed application easy enough Note that Marco Sets the the privileges so Luca is only gonna see or have access to install the operators that He's able to like he's he has the privileges to so when we look at When Luca looks at the operator hub in his OpenShift console he's gonna see you know certain operators in his catalog and Which ones he can install he just goes and clicks install in this namespace And he's good to go So that was my 10,000 foot view of operators what they do why you care There are some links on how to get started. I don't have a learn dot open shift comm link here. I'm sorry But you saw that in some of the other talks But yeah, go take a look at operators go try them out It's very easy to try them out if you go to try that open shift org It'll deploy a cluster for you And then you can go into the console and into the operator hub in the console and just click through and install an operator try it and Play with creating operators on learn that open shift that work. It's it makes it really easy It was the first time I've used that sort of interactive Learning system. It's all in the web browser. You don't need your own cluster or anything. It all happens in your browser Excellent. Thank you