What's up everyone today is Monday, so if you guys don't know every Monday I do a video watch list publicly on YouTube. That's the video before this and then after I'd like to recap my trades So let's kind of get started. I have a couple of house cleaning things I have to talk about first before we get started in 48 hours from this video in 48 hours from this video the price of lifetime is being raised Okay, we are raising the price of lifetime because we are introducing a bunch of new features Tom diesel is trading tabs with lifetime members James is doing two-hour phone calls with lifetime members Joe is doing hour-long screen shares with lifetime members. Tosh and I are doing monthly webinars So this is kind of your last chance to lock in your lifetime rate It is going to be raised in 48 hours and will not be discounted again So either text Tosh at two one three four five eight five nine nine seven to get access or DMM in MIC also in 48 hours We are no longer giving the accelerated course for free So we ran a promotion for an entire month where if you signed up for MIC annual You will get the accelerated course for free Now after 48 hours if you want the accelerated course It is going to be a separate charge of 1497 the reason why is because it took six months to make and No one appreciates anything for free. We gave you a one month window to sign up So again in 48 hours the accelerated course is no longer going to be included and the price of lifetime is going to be raised so What I like to do in these videos is I always like to walk you guys through my process in the morning Kind of show you what I'm thinking in my head And then maybe you could take bits and pieces of my process and plug it into yourself and your own trading So I always say that your process always starts the day before so today is Monday My process starts on Sunday. Okay, so let me kind of explain what happened on Sunday What I did to come in on Monday and where I'm at now So Sundays are usually my rest days. I don't like to drink. I don't like to party I don't like to do anything except sit on the couch all day and just turn into a zombie and just reset my mind Long story short that's not really what happened this Sunday. So this Sunday aka yesterday The tattoo artist that me and my brother go to Made a house call so he hasn't been able to give tattoos because of a COVID so he's been making house calls to like some of his best clients and My brother and his girlfriend get tattoos from this guy all the time So he knows that as soon as he comes he's gonna make a bunch of money So we kind of had like a tattoo party, which is crazy to say because a year ago I would never think that I was even gonna get one tattoo and now I have three So we had kind of like a tattoo party long story short My brother Alan was kind of boasting about the fact that he wanted to tattoo himself So Alan's like yo, like can you let me tattoo myself this and that so I actually got a tattoo So I got three a is on my leg to represent the three brothers in my family So I'm Alex a brother is Alan and my youngest brother is Aran ar en. It's a traditional Armenian name So I got three a's on my leg to represent the three brothers in our family and because Alan is the middle child We had the idea of Alan tattooing my middle leg So go figure my brother Alan for his first tattoo ever Tattooed me and now I have Alan's Hand writing on my body forever. It's obviously not as straight as a tattoo artist. It's not as clean as a tattoo artist It's not as good as a tattoo artist I didn't get any discount for him doing it But the fact that now I have a memory that my middle brother Tattooed me for the first time on my leg with his a initial because he's the middle child It was kind of a cool experience.  I knew it was gonna be fucked up, but I appreciate the memory more That's something I learned from bow is make memories more than anything else So that was kind of my Sunday. So again my Sunday Was kind of different, but I still made it my job I still made it my job to come back home early I still made it my job to get the right amount of sleep about missed it So it's kind of it looks a little bit fucked up because of the angle, but Alan did the middle a it's still kind of healing So I don't want to really show like blood or anything like that But yeah, so three a's to represent the brothers. Anyway, I know you guys don't really care about that That's kind of how my process started, right? So now coming into Monday Monday is usually my worst performing day Why is Monday my worst performing day it is because I am so excited to trade over the weekend And I am so impatient to trade over the weekend that I start to trade pre-market I start to have FOMO and I turn into my own worst nightmare So consciously after doing this for fucking years I finally put a process in place that helps me with Monday morning FOMO and that is no trading pre-market whatsoever on Mondays and If I am up very early in the day within the first half hour of the day I take the money and run rather than trying to force for more So coming to the day I always look at the low-hanging fruit what stocks ran on Friday that tanked that are gapping up today if You look at the chart of VXRT guys on Friday It had a massive move from eight dollars to fourteen dollars and closed around eight dollars again Today it gapped up on no news to eleven dollars So that to me is a perfect low-hanging fruit anyone that bought on Friday is stuck They will get out on any bounce. So there is now so much supply in the stock pushing it down So that was my main watch of the day VXRT the low-hanging fruit that tanked on Friday that is bouncing on Monday So the game plan on VXRT was let the chart form pre-market Let's wait and see what this chart is going to tell us pre-market and then we will attack Fast forward ten dollars rejected multiple multiple times So in the morning our plan was to short of bounce towards ten dollars ten fifty and eleven dollars if ten dollars failed We would be more comfortable adding to our winner. So that's what happened in the morning Stock tested nine ninety five tanked down to nine dollars Bounced to nine fifty the half dollar mark. We like to use whole and half dollar marks. That was also tied with VWAP So how do you just wait it for this low-hanging fruit to tank and bounce you would have made the most stress-free amount of money guys So again the number one stock of the day that I am always looking at is the low-hanging fruit We had a beautiful low-hanging fruit on VXRT today. That was a great easy lay-up trade Now what was the other low-hanging fruit? EKSO So if you look at the chart of EKSO on Friday It went all the way to ten dollars and fifty cents and tanked down to eight dollars and fifty cents or something like that So to me Today when we gap down My goal was to short pop towards red to green. We never got it. I didn't trade it I left it alone and that was it next After that we had INL INL was a stock that trapped on Friday. That was a first red day on Friday and Now who was bouncing back up remark it? Again, we drew our lines. We had our areas of interest I think it was around thirty dollars was the line that we were looking at which was the previous close ramped up to thirty one tanked bounce and tanked So I was too busy focusing on other setups that I was not able to capitalize on that setup. So again We had three low-hanging fruit today. I was only able to capitalize on one So again, let's recap the stocks that I am looking at first the stocks that I want to size in on the most Are the day two low-hanging fruits that people forget about So I just explained those now. Let's talk about Today's crazy stock of the day Today's pump and dump of the day Today's ridiculous stupid irrational move day one of the day BHTG guys BHTG So this stock in the morning pre-market ran up to three dollars and seventy cents As pre-market continued the stock tanked under three dollars So we saw that the chart was formed pre-market.  Those are inexperienced traders. Those are the dumb money Whenever I see these robin hood traders entering these stocks at 9 a.m. I take a mental note of it I tell myself that if and when The trend fails on this stock This is going to unwind in a big way Now if we know that robin hood comes online at 9 a.m There is now a notorious chat room pumper that likes to pump stocks on youtube at 9 a.m. As well It's not a coincidence that he chooses 9 a.m. That's when the irrational uneducated sheep money comes into play So this chat room pumper along with the robin hood guys are pumping stocks out of the moon their goal their strategy is to Their their goal their strategy is to pump these stocks pre-market because pre-market is illiquid pre-market has no halts And pre-market is more jumpy and risky. So these guys what they do is they have 10,000 20,000 30,000 people youtube facebook Instagram linkedin anywhere anywhere that they could put a live stream These guys are coming in and pumping these stocks They're pumping the stocks up pre-market to uneducated traders They're pumping the stocks up at high of the date to buy more buy more buy more and now Knowing that all of these moves are artificial Knowing that all these moves don't make any sense That gives an experienced trader like myself like the traders in m. I see an edge Okay So today my goal on that stock was to wait for all the inexperienced traders All the dumb money to buy that four dollars high of the day buy buy buy buy buy buy as much as you can four dollars Hi there. Hi there. Hi there I wait for the stock to be pumped I do not short it pre-market Shorting these pump dumps pre-market is suicide So listen listen to these little nuances that I'm telling you guys Recognize Robin Hood 9 a.m chatroom pumpers 9 a.m Wait till they pump it from 9 a.m to 9 30 After 9 30 if they continue to pump it still no trade You are waiting for the stock to top out to tank and to bounce Your entry comes on that bounce that dead cap out So on the example today the stock went to four dollars and 20 cents at the open It tanked to I think it was like 380 maybe 370 It bounced towards 390 and four dollars I shorted that bounce Risking high the day. I posted my chart for the members at m. I see I covered up for 20 30 cents Stock rebounded again Shorted again Risked high the day again And did the same process twice So for me, I was a little bit more conservative on the stock today on the hot stock of the day The bftg stock Reason why is because it was monday reason why is because it had a lot of volume And that was basically it so I had no real reason to play conservative But based on my personal stats I get in my head a little bit on mondays So I just don't want to overstay And I think right now the stock is tanking. It's about at three dollars. Does anyone have the current quote?  Okay So, okay, the stock is at 305 now. So it just lost all of its move We're gonna probably wake up tomorrow. It's gonna be at two bucks and it's gonna have an offering So let me kind of explain this to you guys What do you guys now understand what type of market we have? We are in A lot of people are comparing this market to the tech bubble in the 2000s I wasn't around around that time that I was trading around that time. So he has that experience But this is kind of what it was like, right? Everyone that is that has 500 bucks is opening up a robin hood account And they're following these youtube pumpers.  The people that are making money in this market Is or the people that are making money in this market are the people that have educated themselves to realize What is really going on here? Everyone wants to be a trader It is the coolest thing in the world I have friends that sell jewelry friends that sell cars Friends that sell life insurance. They all want to get into trading Their goal as anyone else is to start buying these penny stocks These stocks that are two or three cents and if they go to a dollar, they're going to retire But they don't know that these stocks are going to go under a penny. So that's number one Number two is a lot of dumb monies entering the market There's a lot of bullshit courses out there that are selling for five 10 15 thousand dollars That are teaching you strategies that are from five and 10 years ago There's a lot of people that don't understand risk management And there's a lot of people that literally go on youtube at 9 a.m. And pump their book to inexperienced traders. They make 10 20 thousand dollars And their thousands and thousands of followers lose 10 fold Okay, and because of these big numbers they are able to market that and pump that to bring in new Fucking sheep into the market So guys today's lesson is really simple Today's lesson is to not focus on these hot stocks Today's lesson is to not focus on these crazy up 100 200 300 percent manipulated ass stocks Your goal as a trader is to trade when there is an edge Okay To me when I see a low hanging fruit gap up that is such an edge to me that I want to size in But if I see a day one low flow trade That is a signal that maybe I should take it slow on a monday. So again guys the process works But the problem is do you have the discipline to follow the rules? I was talking with a friend over the weekend And I was saying that you know trading is stressful sometimes trading kind of makes me get in my head sometimes And I I kind of was going back to the fact that anytime Trading stresses me out. It is because I'm at the desk past 10 30 a.m. Right My friends tell me all the time right they say all you talk about is 10 30 a.m. The zombie rule If you just follow that you are profitable If you deviate for even one day if I stay for even one day It turns into a domino effect of stress that harms my trading long term So sometimes Times guys as complex as trading is if we keep the simplest rules If we stick to the basics the fundamentals like the zombie rule low hanging fruit death line and first red day We are able to make a shitload of money The problems occur when we trade pre market The problems occur when we trade with formal the problems occur when we trade day one stocks So I want to challenge you guys to create a process around your flaws guys My flaw was that every monday. I was so excited to trade That I would get in my own head and hurt myself So now I created a process around that no pre market trading on monday Nail and bail faster than usual on mondays leave at 10 a.m. Not 10 30 a.m. Okay Or if you find yourself getting squeezed on mondays take note of that Track it back test it at 10 30 a.m. Maybe your edges to go long If you look at the part of vxrt it bounced at 10 32 a.m. Okay You don't have to hold it all day, but if you realize these little nuances you can make money This is why when myc started we spoke about the process Everyone laughed at us at first Everyone said these guys don't know what the hell they're talking about And now i'm seeing all these guys on youtube talk about the process I'm seeing all these chat room guys all all these old school 10 20 year old traders Now talking about the process now talking about fantasy orders now talking about lines Back then they want to keep it as complex as possible So you guys could buy their fucking five thousand dollar course Now everyone has a process everyone's talking about the process It's the process.  Where were you before myc started? That's the thing guys What me and bow have learned is most of these competing chat rooms are members of myc under aliases These competing chat rooms that have maybe double triple or even half the amount of members as us Are in myc learning what we are teaching and teaching it as their own in their room Good luck motherfuckers because we're coming after you And that's the thing that's really unique about us You know that we have something that works when you have other people trying to follow us and copy us and learn from us All right Do you guys have any questions for me? Let's kind of open it up to a brief Q&A Also, let me just make note of this guys is I spoke about this in last week's youtube live that I haven't really taken a day off In a long time So I want to announce that starting tomorrow. I'm going to take the week off from trading and from myc This is kind of a mental health Vacation for myself I've been working nonstop for about four or five months in the confines of my office Not really hanging out with people not really doing anything crazy So I need to take some days off for myself And it just so happens that the market is closed on friday 2 in observance of fourth of july So I will be taking uh tomorrow Wednesday and thursday off I'm going on a road trip with my dad We were actually going to go today But I decided that I want to stay one extra day to put out a video watch list out I want to stay an extra day to help you with one of these video recaps Uh or else I would have just gotten today, but it doesn't really matter.  I mean with the moderators Please be patient with the videos coming out Just please be patient with everything guys. I just really need a couple days off to clear my head. Um Another thing that I want to talk about is Every wednesday we host a webinar a free public webinar for beginners This is kind of like a special look inside of m i c We've kind of rebranded it to the reversal hour show with tosh So imagine a talk show now that we're going to kind of do every wednesday Where tosh is the j leno and he's going to bring on some guests to talk and hang out So every wednesday at 2 p.m. Be sure to tune into youtube or zoom we post the link and we kind of have a great time But other than that guys, let's open up to a very quick q&a I want to answer these questions.   So it's a funny story guys. I actually have a rule I have a rule where I am not allowed to trade on vacation The reason why i'm not allowed to trade on vacation is this I've traded on vacation in the past very many times And there's two things that happen number one I either sit in my hotel room and make a shitload of money and waste my morning relaxing and just making more money Because an extra two thousand dollars isn't going to change my life.   Um, so another another thing that I want to kind of make note of so that you guys understand is Small caps have been on fire guys. Um It's kind of like a big bubble has been really happening Small caps used to trade on a very uh on a very good day a small cap stock would have traded maybe about 30 million shares But now on a normal day, right on a normal day Uh, these small cap stocks are trading with 100 million shares So there has been more volume entering the market There's been more demand entering the market and it seems like more people are buying these scammy ass shady ass companies So what I've learned in this market is very simple guys There's no point of attacking pre-market. There's no point of attacking on front side Front side and pre-market are suicide If you want to make the real money, all you got to do is wait for the chart to form All you got to do is wait for the top to form and short the bounce after the top is set That is the highest reward Lowest risk lowest stress strategy that we teach inside m. I see So if you look at all the stocks that we're running today guys, how do you just wait it for the top to form? How do you just wait it for the bounce?   Come play with us.  This is my job. This is my profession Okay If you want to make the type of money that we are making This year so far knock on wood.  We have been educated so well That we know exactly what to do when these guys enter the market guys So please I challenge you take advantage Of the 48 hours left for this promotion If you do not believe that this is going to help you go to instagram.com slash my investing club Look at our uncompensated unpaid testimonials from real members Uh question is there examples of a video on the first bounce strategy guys We have 30 40 videos on this stuff. We have 800 member only videos guys Do not ask questions that you know the answer to All right, youtube is your preview youtube is your free trial to m i c we provide daily content there guys So please do not be lazy if you are struggling in this market and you are not making money If you lost more than 200 today that pays for a month of education If you lost more than $2,000 today that pays for a year of education, okay So please guys take advantage of this market and get away from my ex-girlfriend I'll see you guys in the room and be sure to text tosh at two one three four five eight five nine nine seven


I don't think that there's another Linux YouTuber out there that has done as many videos about file managers and file pickers than I have I've done some many that people might think I'm a little bit obsessed with it and there may be some truth to that I mean cuz really how much energy should one spend on actually talking about file choosers and file managers I spend way too much on it. I'll be honest about that now about six months ago Maybe a little bit longer than that I made a video talking about how file pickers on Linux are terrible and I stick by that that I think that the worst part about Linux that I can even say is that the file pickers are just so bad They're fragmented mess and none of the ones that are used are good in any way they're just varying levels of absolute terrible garbage and That has just been the case forever and it doesn't seem to be something that Anybody's interested in solving and I'm not talented enough to go out and solve it myself So maybe someday that can happen. I'm learning some coding, but we'll see how it goes but anyways the thing is is I though my dream is to be able to use Ranger as my file picker and For years now that dream has been unrealized until today because today my friends I have learned how to make Ranger the file picker for a browser now to be honest It's cute browser So if you can't use cute browser, then I still have no solutions for you But if you are a cute browser fan or if you use cute browser There is a way to make cute browser use Ranger as its file pickers file chooser, whatever you want to call it and That's what I'm going to show you how to do today. It's really really simple and I'm I've spent the whole morning playing with it, and I'm just so happy I'm such a nerd Anyways, let's go ahead and show you how to do this. So let's go ahead and go to the terminal here and we'll go into my dot files and Then CD into cube oops if I can actually type this keyboard is so bad cute browser I bring I blame the keyboard when I miss type stuff. Yes, that's the what that's just the way it is anyways Anyways, what you need to do in order to enable this obviously you'll need Ranger installed Okay, so you can't do this without Ranger and you'll need to figure out what your default terminal is So obviously if you probably know this because you probably use your terminal all the time if you use Ranger But you need to actually go through and figure out what the syntax for calling that terminal is from a prompt So for example, if you use alacrity, you'll need the dash E flag now The deep the dash E flag is pretty much standard for most terminals I know most of them use it But just check with your the man page of your terminal to make sure that that's the flag You'll need to use in order to open up a terminal with a program already running I'm using alacrity because it has a special feature that allows you to define a class name for that specific terminal So when I open up Ranger using the file picker now and keep browser It has the class of Ranger that way I can define a rule in DWM that allows it to be floating So that's really cool as well. That's not something that I that any other terminal does as far as I'm aware kitty Might do that. I'm not sure but I know Ranger does do it and it's awesome So here are the lines you need you need config dot set and then parentheses quotation marks file select dot handler quotation marks comma quotation marks external quotation marks parentheses Okay, and then you need this one here. I'm not reading all this out Anyways, the the commands here I'll copy them down in the video description below so you can just copy and paste Obviously the only thing you'll need to change if you're using a different terminal Is this here? And then if you're not using alacrity, you'll need to get rid of this these two Parts here because like I said, this is alacrity specific And then save this you add those two lines It can be anywhere in the config dot py file and obviously you'll need to be using the config dot py config file for cute browser in order for this to work if you're using the The graphical gooey settings manager that doesn't use config dot py you won't be able to do this as easily You probably there's probably settings in there for you to to manage this. I'm not sure I never used that so You have to have the config dot py enabled in order for this to work Okay, so once you've done that and you've pasted these lines and Save that file and then we can go through and open up cute browser So what better place to do this than on unix porn? Let's go ahead and upload a file here. So we just go to image and video upload and then voila We have ranger as our file picker. So we'll go ahead and go to my pictures here It'll work And then when just found the file that you want to upload hit enter and there you go. That's how you upload with with ranger so there is a way to Go through and upload multiple files as well And it's just how you'd expect when you want to select multiple files in ranger You use a spacebar to select them and then you hit enter now red It doesn't let you upload multiple files, but that's how you do it on a site that you needed to upload multiple files to And then you just enter and it would upload them now the thing is this is not perfect So in my brief time of using this this morning I've experienced some errors. So sometimes you'll get like a 403 error or something Or it will say the renderer crashed. I'm assuming that's either a bug with cute browser or a bug with ranger I'm not sure what that is. I'm gonna file it on their github later on when I see it again But just to keep that in mind that it's not a perfect solution Right and there's some Bugs that still need to be worked out. This is a fairly new feature. It just came out and cute browser 2.0 I think last year maybe the year before i'm not sure now Time flies just so fast. So it's not perfect I I've also noticed that sometimes ranger doesn't like navigating in this mode for whatever reason and it'll just show You know files in your directories. I've had that happen a couple times Just closing ranger and opening it back up with the proper steps to you know, press upload or whatever and It will open up the file picker, which is ranger and it will it should fix that problem as well So there are like I said, there are some bugs, but otherwise This is amazing It feels like such a weird thing to care about But this is a reason enough for me to go back to using cute browser because the the file picker for Firefox is horrible just like all the other gooey file manager file pickers are And I upload in a files that this is something that is going to affect me every day It's going to make me happy just to see this every day because I like rangers so much more than that generic gtk file picker that uh firefox uses and It's just one of those things that will improve or at least make my linux life a little bit happier and I think that that that's a good thing. I really wish that I could get this working in firefox though Because firefox has good ad blocking or at least you can add good ad blocking a cute cute browser Not so much. Anyway, so that is it for this video If you have questions, you can leave those in the comment section below Make sure you like and subscribe if you haven't already You can follow me on twitter at the linux cash You can support me on patreon at patreon.com slash linux cash before I go I'd like to take them think my current patrons Devon chris east coast web gen 2 is fun too patrick l primus sit a marcus maklin jackson I'm the tool steve a michael arson and emma taas merrick camp josh li day dog the bsd's rock and peter a Thanks everybody for watching. I'll see you next time


Essentially the difference between Ayurveda and Siddha and allopathy is just this. Allopathy is purely chemicals, chemical manipulation of the system. When it's an emergency you must use it. But if it's a long, you know, if it's a chronic ailment which is going to be with you for a long time and you're going to take some medicine for a long time, definitely popping pills for long periods of time is not a good thing. So Ayurveda is horrible. Herbs are also chemicals but in natural form it's way better than taking it in a synthetic form. Ayurveda needs a certain amount of application and knowledge because there are over three hundred thousand, okay, three hundred thousand Ayurvedic formulations according to the ancient texts. Three hundred thousand formulations you have to understand if you have to really prescribe Ayurveda. So prescribing or practicing Ayurveda is a… it needs a lifelong involvement. These days I see people come from outside the country, they study Ayurveda for one and a half months and they're certified Ayurvedic teachers or doctors, practitioners. It's a very dangerous thing to do. Three hundred thousand formulations, how to give it, whom to give it, when to give it, it's not a simple thing to understand. It takes a lot. Above all, you need a phenomenal understanding of the body to be able to prescribe this. Siddha is very different in the sense, Siddha is essentially elemental in nature. There's… there are herbs but essentially it's elemental in nature. It comes more from the yogic science because the fundamental of yogic science is in Bhuta Shuddhi or in cleansing of one's elements. This is an evolution from the yogic science and Siddha Vaidya was essentially formulated by Agastya Mani and they say Adiyogi himself practiced it and Agastya brought it to the south and only in the south it lived nowhere else.


Well, we'll get started. Welcome to our discussion on upgrading. My name is Charles Bitter. I work for Comcast. And they've asked me to moderate this panel discussion. So we'll jump right off and do a quick introduction to each of our panel members. So we'll start right here. All right. Hello. My name is Siddharth. I work for VMware. Actually, on the implementation of the team implementing the upgrade for VI or so, I have a different perspective. My name is Mark Felker. I'm the OpenStack architect at VMware. Hi. My name is Basil Baby. I'm with the cloud engineering of Comcast. Hello there, folks. My name is Stephen Dake. I work for Cisco Systems, where I'm bringing containers to OpenStack, also in the call of PTL, and worked on Magnum briefly for about two cycles, as well as started the HEAP project in the past. Hi there. My name is Tom Howley. I work in Hewlett Packard Enterprise. I'm working on the life cycle management team. So that's primarily involved with the deployment and upgrade of OpenStack. Hello. My name is Michal Jastramski. I'm a worker in Intel. And I'm a part of Cola Core team. And I've wrote most of the Cola upgrade logic. And I'm Jan Grant, Hewlett Packard Enterprise, also working on the HLM team, dealing with deployments and upgrades. So that's our panel. Before we start, we'd like to get an idea about our audience, even though you're kind of dispersed. Who in the audience, and keep in mind, we can barely see. Who in the audience actually operates an OpenStack cloud? And who has ever upgraded OpenStack? Who hated it? All right. Who wants to? Deal. Cool. All right. So my next question is for each panel member. Take about two minutes and explain what kind of cloud you upgraded, what version did you go from in to, and just some basic considerations around that. All right. So well, essentially, we have upgraded OpenStack cloud for some of our customers who have deployed it in production. And we basically upgraded from Icehouse in our version one of the product to Kilo through your jumping release. And we did upgrade to Kilo for them. In terms of the challenge, I guess. Well, for us, essentially, one of the important part was with our customers, considering that they were in production with that, we had to plan out in terms of what sort of requirements. We had to clearly lay out what additional requirements do we need for them before even they start with the upgrade. Because we wanted to make sure that they succeed the very first time when they try and do it. And they don't have to go back and put off the fires along the way. So that was very important for us. And I think so far for our product, with our customers' experiences, it has been really very good. In fact, some of our customers, they actually went ahead and been brave enough to do it themselves without even telling us. And they were quite successful with that, which is actually very positive for us. Yeah. So we did our upgrade on from Havana to Isos. So it was a full production environment on multi-region. So the challenges side, since it's production and a lot of customers, the workloads were really different. Like, we have connected boxes directly to the VMs. So the planning part, it took some good time to plan the upgrade, see it in really action, port some of the data, what we are seeing it in production in the lab, do the same kind of deployment methodology on the lab, and then upgrade and see how it works, collect all the data, what breaks, hydrate through that, again, do the upgrade many times. So the main challenge was, since it's production and getting a lot of production traffic from diversified tenants. So that was the main. Yeah. Thank you. So I have personally upgraded from Liberty of Kola to Mataka of Kola with running VMs without any interruption of the system. Kola is a new project, so we're not upgrading from Ice House or Kilo or older distros, distributions of OpenStack. I would say the key point or message I would make to people trying to do upgrades is what often happens is folks deploy a system. They get five or 10 folks together and they deploy an OpenStack system and they say, oh, victory, we're all set with OpenStack. But they make a mess during the process in a lot of cases. And that mess is very difficult to clean up in an upgrade. So one of the key factors of Kola, one of the reasons it makes its upgrades so fantastically good is that it does not make a mess of the system. So there's no mess to upgrade. And that's really the key value of upgrades in Kola. All right, Joe. So two parts to my experience would upgrade. So originally, we were running a public cloud. So actually, the first region we had deployed was Diablo and we did an upgrade by jumping much later on to Grizzly in a separate region. So running that public cloud, we upgraded from Grizzly to Havana and through to Ice House for most of the services, I believe. So I think that fed into our, we got a lot of experience from the problems we would have had, because it was early enough days and an upgrade. And I completely agree with what Stephen said. You need to deal with and think about upgrade from the beginning when you're doing your initial deployment. So more recently, as we kind of moved to actually providing a product, that we have an upcoming release, which is basically going to be an upgrade from Kilo to Liberty. And we're currently working on the Liberty to Mataka. So that's kind of two aspects to our experience. One is in running a public cloud and doing it possibly more manually and running into lots of problems with conflicting dependencies between packages and the various services. And then I think we know we've dealt with some of those issues in our more recent upgrade mechanisms that we've implemented for the product. So I upgraded OpenSync Seems Havana actually on the multiple occasions. I'm a more developer than operator, so I was more playing about upgrades. And since they have Havana app, all the experiences I had, I gathered, and that was the base of the Kola automatic upgrade script. So in Kola, all that experience was gathered and brought, actually, automated upgrades from Liberty to Mataka and from Liberty to Liberty security patches as well. Yeah, obviously I work with Tom, so let me just add to that. With the initial upgrade in the public cloud, we had the fantastic luxury of opening up a new data center, which obviously, if you can manage that, that'd be great. And then playing a shell game with the original region as we managed to get our cohorts stood up. That obviously is not on the cards for most people. And I echo what Stephen said, the more you can containerize in whatever fashion your software that you're running, the better. It puts you in a much better position. So let's bounce off that. Let's talk about containerization and automation. I know that the Kola project is all about containerization. And I'm getting the theme that you don't upgrade without automation, right? So can we get a quick snapshot just so everyone kind of gets an idea of the automation tool sets that you used? So let me start with this. Most importantly about why containerization is important from upgrade perspective is the separation of the dependencies. So for example, the big issue with upgrades is I want to upgrade my Nova. But Nova uses Oslo in version x.y. And I want my neutron to be upgraded a day after when we confirm that Nova is actually working. But it also uses this older version of Oslo, which means I cannot run my Nova and neutron at the same time in the middle of upgrade, which in essence turns out to be we need to upgrade every single service at the same time, which is disruptive, which is hard, and which is extremely hard if not impossible to roll back if something goes wrong. In Kola, actually, any form of separate containerization gives you the one service has its own set of dependencies, which means we can have multiple sets of dependencies coexisting at the same host. And that, in essence, give you the ability to upgrade just Nova, for example, which means the upgrades are more atomic, less volatile. And actually, they are actually quicker when you consider that because you don't need to deal with the conflicts in the process. The other nice thing about Kola, it is actually image-based specifics. So Docker is that when you have pre-built images, you can test them out prior to the deployment so you can make sure that your upgrade works before you actually upgrade it. And you don't download any form of packages in the meantime. So when you do upgrade and the repository with your new version of packages dies, it will not affect the pre-built images, which is yet another way to make it more less volatile, actually. So with Kola, we have multiple ways to deploy Kola. However, our main one is Ansible. And with Ansible, we have a set of play. I mean, we have a playbook for upgrades, which assumes that you deployed Kola with Ansible. You can just run the playbook from upgrade. And because of the atomicity of the upgrade, because we can do one service at the time, we could do it automatically. Yeah, we run into some of those same constraints. And we have a lot of the same philosophy, I think, about kind of containing things and making sure that they work before we actually flip the switch and put them on in production. We tend to think of upgrades actually as maybe not atomic, but more transactional. In most cases, when we're doing upgrades for customers, they have a set of things that they want to get upgraded. And if that's one thing, that's one thing, right? It could also be 12 things. Maybe they want to upgrade every service from Kilo to Mataka. So we tend to think of it as let's test that entire system all together and make sure that the whole system works before we turn the switch and put it on in production. And because of that, we do a blue-green upgrade pattern where we can actually get a control plane that we know works together before we actually flip the switch and put it into production. So we have a lot of the same philosophy there. Well, it's essentially a staging environment. And however you do it, the best way you could do it is to upgrade one service, test it out, upload the second service, test it out, up to the point of upgrading everything. So you basically replicate what you will do normally on production. And thanks to the image-based deployment, you are guaranteed to have every single thing in the same way you tested on the staging in the production unless you broke something yourself. However, so I mean, I agree with you. You need to test the whole procedure to make it to be sure. Just to add, we completely agree with the need for isolation to dependencies. We basically achieve that using Python Virtual and so it's not quite going the full distance as container. But this definitely solved a lot of the issues we would have found in the public cloud experience in terms of conflicting dependencies between different services. So as you said, it doesn't go to the length of the container because there are C libraries. This is a significantly less of a problem than the Python libraries. There are hundreds of Python libraries in the requirements right now. There are only several C libraries. But to have the full separation, you need to go all the way. But it requires more from the deployer to go all the way from day one. So we see a pattern, right? We need automation and we need isolation. We can isolate at the Python library level, a Docker container level, an entire image level. So that isolation, I think, is super, super important for rollback. But how do you know to rollback? So tell me about how you test your upgrade. Well, I'll just go around and start right there. You have a mic. OK. So we actually test upgrade both in CI and QA. We're in a slightly different position that we're now preparing a product. So whereas with the public cloud, we were looking at very regular cadence of updates with small deltas. Now we're looking at maybe one or two releases per cycle. So we have some luxury of being able to test and test and test again. And we've got a good idea of what's deployed currently. We've got quite a bit of flexibility in our deployable architectures. So fortunately, we have amazing QA people as well. And that really can't be stressed enough that they come back to us with all sorts of things and say, well, what about if such and such happens? They say, why on earth would anyone ever do that? But it's something that needs fixing and sorting out. So with the more flexibility you've got in your potential deployments, obviously, if you have one particular sort of virtualization technology in mind or one particular kind of back end storage for Cinder, you, with your own site, you can scope your testing. But I think the real thing is to, before you enter an upgrade live, you want to know damn well that it has a very high probability of passing. And whether you do that starting small with a virtualized setup, we use much the same tooling for our developer environment using a vagrant-based system, which is a reasonable fidelity model. So our developers are using the same tooling right from the start as we then use on bare metal and so on. So we do it again and again and again to really find out where the weak points are and those are the things you've got to focus on. So having said that we've finished, you have to finish the upgrade is not actually a trivial thing to say because we may forget about upgrading this one particle package on this one of the 100 nodes. And that's the reason we need automation. With Docker, it gets a bit easier because to validate that we actually upgrade it is we had this set of images on day one. And these are images valid for labor key. Then in Mitaka, it's this set of images. And in every single node, these images, the Mitaka images are up and running. And everything was running in the meantime. And if everything obviously is running after the upgrade, you pretty much are done with the upgrade. So your state of your cluster is very easy to figure it out, which is not a trivial matter. So as for how I tested upgrade, well, I just did it probably dozens of times right now and test deploy liberty, deploy VMs, ping VMs, make upgrades, see if everything's working, and tear down the rinse and repeat. Just to add to what Jan said. So we, as he said, we have a vagrant environment for developers to test deployment and upgrade. And we use that same tooling for CI. I think when we first introduced upgrade, and we did this early on, so with the first release based on our first Ansible-based release, we actually had upgrade pretty much implemented, even though you don't really need it until the next release. And it was a bit of a challenge, actually, introducing that across the various services, getting your first kind of upgrade CI job to work. So we have a CI job that runs on many commits across the various repos. So as a result, we're testing upgrade thousands of times by the time you get to release. Now as Jan said, because we have flexibility in how you can define your cloud in our product, we can only test a certain set of patterns and try and be smart. And indeed, one of the issues you get with this, you know, it's great putting stuff into CI, but you only have a limited set of physical resources to test. So you kind of have to be smart about what you want to test. And I think we're looking, you know, within ourselves to streamline some of the CI so we can actually test more kind of more intelligently on the various different services. So, you know, what are the issues with upgrading Cinder? And to be honest, actually the more, the kind of problems we found in CI are not around upgrading OpenStack services. It's actually around upgrading the infrastructure services so that keep alive DHI proxy for Kona. And you find some very interesting intermittent issues when you run upgrade thousands of times or even hundreds for. And what's been very useful is actually, you know, together with the kind of an Elk stack in the background, building up stats to figure out, okay, this issue actually looks like it's gonna be important for us to address as in it might happen on a customer site, because you can't address every single issue that CI throws up. It has been very useful as a kind of initial testing ground and then obviously QA is invaluable after that for kind of full testing on bare metal. So I think one thing that's different about Kola versus other deployment tools is Kola is meant to be an upstream for other downstream products. What that means is people take Kola, they maybe make some changes to it and they ship it as their product. As they do this, they qualify the upgrades. That said, we definitely wanna qualify our own upgrades before that happens. The way we're doing this in this next cycle is we're adding co-gating jobs for Glantz. We're gonna add a co-gating job for Nova and a co-gating job for Neutron. They test the upgrade from one version of Glantz to the next or one version of Nova to the next or one version of Neutron to the next. As well as a gating job for all of the deployments or all of the packages we deploy. So we will have that co-gating job. Those co-gating jobs will detect failures in those services as well as kind of our regular gating job which will detect failures in our infrastructure based around upgrades. But our upgrades are so simple and so straightforward. They were hard to implement but they're so straightforward to look at now that they're done. I don't expect a lot of problems. That said, there could be problems. And I think it's really up to the downstreams that use COLA to make a decision as to how they wanna test and qualify their products based upon COLA. Yeah, in a Comcast story like some of, I mean, a part of our infrastructure was already, was built like sometimes back. So like the survey released in like this release cycle, I think 50% of the users are still on Isis or behind I believe. So we had the same thing like, even though COLA is good and all those good things came after. So we are stuck on some of the older, some of the infrastructure where we are stuck on the older version. So the testing part, like for the question you asked, we start with the way ground like I think if you all are doing the same. So we start with the way ground and then in our case, like we are using Puppet on this Isos and when we are using Puppet and we orchestrate through Ansible because we already have the manifest so we don't want to rewrite or make a big change there. So we used Ansible to orchestrate that runs because Puppet, it is not that good in the timing, like how to time the runs. So and in the production, while doing the production side, we are using Tempest test, like after the controller upgrade, we run Tempest test to make sure that the existing clients are good and we can create VMs or delete VMs. All those operations are fully functional. The control plane is really good. Then we'll go to computes one at a time or in batches based on the region where the kind of workload we are putting into the region and then we go in batches to do the computes. So Tempest was really helping us. So we wrote some custom Tempest ones to fit our needs and the rest of them we are using from the community itself and that was really helping us. So kind of interestingly, we being in the product space, we don't actually always get to define acceptance criteria for an upgrade because all of our customers wind up with different things that they consider to be working and not all of them are even directly in OpenStack's control. So for example, we might have customers who actually want to swap out hardware as part of an upgrade to a new version of OpenStack. You know, add new storage, add new hypervisors, add, you know, whatever else. So in our case, in addition to some of the strategies that we've already talked about, one of the things that we wanted to do was have an open window where the customers could actually go in and do the things that they consider to be tests for their particular use case, which again is kind of one of the reasons that we gravitated toward a blue-green upgrade. Once we stand up the new control plane, that gives them a chance to go in and break it however they want to. And either say, yeah, it's good, now actually flip over to it in production or not. And that kind of dovetails into your original point about rollbacks being important because we don't always know those acceptance criteria ahead of time and because they're so different from customer to customer. It's really important for us to be able to very quickly flip a switch and declare an upgrade failed and get back to working very quickly. With a blue-green upgrade, we can actually do that because we actually still have the old control plane. And the really nice part about it is even after we do that flip back, we've still got the new one that they considered failed. It's hanging around, it's not being used in production. It's been cut off from the outside load balancers. But now they can actually go in and figure out why it failed. Because they can actually, they've got it still there to do forensic analysis on. So it felt like a boss, right? Right. Awesome. So I've been leading this discussion for a while and now it's your turn. If you have any questions, we'd ask that you use the microphones so we can record it. Hi, my name is Aniket. I'm from Box. We're rolling out open stack liberty on a massive-scaled box. And what worries me is when I hear a lot of open stack users talking about still being on Ice House or being in June or even few ones being on Kilo, why do you think it is such a problem for customers to adopt near current releases? Any thoughts? So one of it will, ironically, will be because upgrades are hard and they used to be hard and used to be horrible a couple of releases ago. Horrible to a point that you will lose your product, you will lose the connectivity to your workload during an upgrade. So because the early upgrades was pretty much setting up new environment and telling your people to migrate on their own. And that's a very costly procedure if not impossible. Later upgrades were sort of about migrating, life migrating to virtual machines and that may not be possible. It was only like last two releases when you can do the upgrade without significantly or any effect at all of your running workloads. So cost of upgrade will be my best bet. Yeah, I guess my perspective is a little bit different. For many of our customers, at least for a year or two now, I guess, upgrade has been a problem that there's been sort of tractable strategies for now. There's kind of a lot of lore in OpenStack about how bad upgrades used to be. And I think you're right, it's improved dramatically in the last several releases. In our case, what we actually hear from a lot of customers is just it's working really well for us and we don't necessarily need the new stuff that's coming up. So we just don't have a good reason to change. So it's kind of a, if it ain't broke, don't fix it more than say once a year. Got it. And I have a follow-up question for you about the blue-green strategy you mentioned. That strategy essentially involves fencing off one cloud, right? Not the entire cloud, just the control plane. In our case, that's a set of virtual machines. So it's half a dozen or so in some deployments and up to about 13 or 14 others. I see, okay. So that way you minimize the infrastructure overhead of doing that. Yeah, so we have a pretty decent decoupling of the data plane and the control plane. And the only thing that we need to do the sort of duplication for is on the control plane side. In most cases, that's like a trivial amount of resources. I mean, if you're talking about a dozen VMs for a cloud, that's not really very much, in most cases, as it turns out. The biggest constraint we run into on customers is generally they want a couple of extra IP addresses. And as long as they plan for that upfront, then it's fine. All right, thank you. Hi, thanks. I was wondering about database versioning and upgrading of each services and their database versions. What does that look like and are there any pitfalls? Yeah, okay, we can talk about that. So we, in terms of database versioning, are you talking about the schema migrations that happen between versions of OpenStack? Yeah. Okay. So in Blue-Green World, that generally defines what our state sync period is gonna be. So basically the sort of simplest way to do that in Blue-Green Upgrade is basically at some point, you say I'm ready to cut over to the new control plane. That's the point at which I maybe take a dump out of one database, run it to another, and then run all migrations, right? Or even just do that in place if you've got a backup or something. That generally is the period where you don't want things to change. It is possible, and I've seen it done in other distributed systems, to actually have data coming into both the new and the old schemas. I don't really recommend it for a system like OpenStack. And that's partly because we have a whole lot of different projects that are doing their own things independently of each other. It just becomes more complex than you would want it to be. How might you stop the changes, the right requests coming to the database? Sorry, can you speak up a little bit? How would you stop the right requests from coming to the database? You said you'd stop things from changing. Oh, how do we stop the old instance? Yeah. How do you stop the new request from again? Yeah, so generally we advise people to basically cut it off with a load balancer. For most everything, the public interface to OpenStack is the load balancer, and in our case, it's also all our internal requests, like Nova talking to Neutron also goes through an HA proxy pair. So we can generally cut it off there. So let me add to the, lately in OpenStack, I mean, again, about two or three releases, there's this idea of lockless upgrades that Nova implemented via their services are about to implement. It's the idea is that you keep your old database, I mean, you upgrade your database before you even touch the code, which means the new code is supposed to be working with the old database, and sorry, the new database is supposed to be working with old code, and obviously with the new code. That being said, OpenStack services doesn't support, I don't think any OpenStack service supports are rollback in upgrade, rollback of database, which means when something goes wrong, I really suggest you snapshot your database before doing anything with it. And but in ideal solution, which actually, in ideal situation actually is pretty often, you just do the database migration prior to even touching the code, and once the migration is finished, and your localities keep running, you just upgrade your code. And if it's not the case, then you need to just put the maintenance window, turn off the APIs, stop people from making any changes, upgrade the database, upgrade the code, start APIs. Yeah, that's sad as well. It's a good point about the APIs. One of the things we've actually looked at doing, we haven't personally implemented this yet, but one of the things that we looked at doing, depending on how long that state transfer takes, what you may actually be able to do is just basically hang the connections at the load balancer rather than cutting them off and returning error codes. And essentially then you've got requests that don't ever actually fail. They actually just take a little longer. So there's some balance on that that I'm not a big fan of. I mean, if you have a really massive amount of data to move and you're skipping 16 OpenStack versions and really want a whole bunch of migrations to run, that could be a really long period. And most of your clients would probably rather you just fail. So, but it's a thing to consider. I think we have a kind of similar strategy around performing the migration before we switch over to the new service. And to McHall's point, there's, until we've implemented this across all of the services, the support for old code working against new database and we can't, there's no way around actually stopping your services at some point. And so there's nothing we can do until this is, it's a common mechanism that we have, that they have a nova has been adopted across all the services. And I'm not sure what state that is in at the moment. So the approach is that Novatov is actually more political than technical. I suggest you, if someone is interested, Dan Smith from Nova, it's Nova Core team, he wrote a blog post about this particular thing. It's about just don't make a migration that will lock down your database. And if you actually need to delete something add one release of the deprecation, which will end up you not using a column, but it's better than stopping your service. So obviously it depends on what release you're starting from and where you're upgrading to, but could some of you talk about the amount of time that you plan for an upgrade? Like is it, on your teams, does it take one month or a couple months or a week? And could you discuss that process a little bit? The timeline line. So let me break a little bit because we tested an upgrade. So Cora makes things significantly quicker and granted we didn't have heavy database load. We have pretty much anti-database. However, on 60 or so nodes, physical running cloud, it took 12 minutes to do a really subgrade. It will be more if you have more data, obviously, but basically unless you are really, really heavy on database, it should be less than two or three hours of total process. Image-based deploy really makes this faster. The non-color world, I can give you some perspective. So if it is not on the container world, things will be like a little more difficult. The planning, you need more planning. So that's what we faced in the output. So we planned like the planning and execution total took like a month plus. So it was multi-region. So we had to coordinate with the users within the cloud was like different kinds. And it's a multi-region. So we had to do some sort of coordination of these upgrades. So it was like a month plus. Yeah, I'd just like to straighten something out. So Mihail talked about the 25 minutes for deploy and the 12 minutes for upgrade with the database. I really don't think it would take two or three hours to upgrade a really heavy database because the migrations are relatively quick. But it might take 45 minutes. The thing is we don't have to do a lot of planning with our upgrades because our upgrades are systematic and deterministic, idempotent, declarative. I can go on and on about how technically they basically are always repetitive and work the same way every single time. So because of that, there's no planning that's really necessary in a container world, at least with COLA and maybe with other container deployment tools there is, but definitely not with COLA. Yeah, and to kind of tag onto that as well, when you think about how long it takes to do an upgrade, I would submit that in many cases what you actually want to think about is two things. One, how long it takes to do the full upgrade. And the other thing is how much of that time is actually outage because the two are not anywhere near the same. So when we're doing a blue-green upgrade, the time that it takes to stand up the green control plane is not outage time. Customers are still up and running on their old control plane. They can go test that new control plane. That's not outage time because they're still running on the old one. It's only when we do that state transfer that there's actually any possibility of an outage time. And since, in our case, we can't actually determine all the tests that they may want to run, that works out very well for us because we can still bound the actual downtime. And customers can take as much or as little time as they want. In terms of planning for upgrade, I think kind of useful comparison with, I think similar to what's been said about color, we have a standard mechanism that we use for upgrade that doesn't essentially change between releases. And this upgrade mechanism is not just for open stack release upgrades. It's also for interim security patches, minor updates, that kind of thing. And I just happened to be talking to somebody, a developer that would have also worked in the public cloud back in the day, and he reckoned it was probably a couple of months planning well, planning and execution and then upgrading a service that he was interested in in the public cloud. So it's been a radical change. Once we had a mechanism that we worked on for the first upgrade, once we'd figure that out, then it's literally just changing the input data in theory. I haven't said that. We will run into issues, but that's just issues that you need to solve at that point, whether it's an issue that's been introduced by that release, but the mechanism is essentially the same that we had before. So I will add additional caveat to this downtime. There are two types of downtime. One is for control plane. The other one is for data plane, which is the actual VMs. And as for now, for Liberty to Mintaka, we haven't seen any downtime caused to VMs themselves, which means VMs are keep running. They work, the network is there during the whole process. For us, it goes for the data plane downtime. Some of the services like Nova is actually almost, I mean, it's actually rolling upgradable, which means there is no downtime during an upgrade for Nova. There are services that actually causes downtime, mostly because of incompatibility between schemas. However, often consider with Kola, it's pretty much determined by the length of the database migration. Apart from that is minutes on top of it. So if I, I'll give you 30 seconds then. The basic rule of thumb here is you wanna be able to reason about the process. And if you've got a, if you're installing a whole bunch of packages on the system, that is an extremely complex set of potential interactions. If you're talking about components of services, and you can reason about those in isolation, you're in a much better state of to actually work out what's going on, to figure out what's going on, to plan, to understand, because it's all about comprehension really. Now when you're in the hot seat, you gotta be able to know rapidly, is this good, is this bad? And decomposing things into the right level of granularity. That's some, that makes all the difference. Brilliant, so we're out of time. Apologize if you still have questions. We can probably take them over here. And thanks for coming. Enjoy your summit.


In Tairaba state, Kevna Kefas Aibu has promised to address inherited unemployment challenges, illiteracy, marginalization and lack of access to resources. Aibu promised to create an enabling environment for all in the state to succeed. According to him, his passion for Tairaba is driven by the commitments to social justice, welfare and equity. Tairaba has so much to offer to all, and we work with international business community which showcase the opportunities that exist in our land, which can only succeed when working in collaboration with all our communities. In addition, his administration will focus on 13 mentorship products and supporting initiatives by the courage, innovation and creativity.


This is Witchspace news for Friday 5th February 2021, I'm CMDR Buur. In this weeks news, Frontier answers more Odyssey questions, a new CG marks a possible change in policy at Frontier and the itchy subject of the enslavement of new players in the game. If you enjoyed this video remember to hit like and subscribe and if you'd like to help support the work of this channel you'll also find us on Patreon, links to everything you need are in the description below. Frontier released another of their regular Odyssey answers forum posts today, this time dealing with the subject of first footfall on planets in the upcoming legs focused expansion. Whilst again relatively light on any significant details the questions do cover off a couple of salient points. Most notably for us with the fact that not all landable planets will be explorable on foot there is still the element of survivability to deal with with the extremes of gravity and temperature for example in some cases making that impossible. With that said Frontier have clarified that the number of landable planets will be going up by 20% and when you're dealing with a game that has planets numbering at the very least in the billions 20% is quite a lot. For the full read on all the questions answered check the link in the description below. Elsewhere Frontier confirm this week that first footfall will not be dependent on selling data as is the case with new discoveries currently. Actually putting your feet on the surface of a new world will be enough and it will be instantaneous. They have also said that you'll be able to transition from your SRV to on foot gameplay but when questioned how that transition will work they said only that the transition will be quote as it is now but obviously we can't get out of our SRVs currently so we're assuming they mean fade to black as with SRV and SLF transitions. A question was asked about how death of your player character will work and if you'll respawn somewhere and how and if that respawning will be handled in law. Frontier have said that they are still reviewing a number of factors involved in any processes around on foot death and are looking into what solutions work best. On the subject of the distress call mystery that was dropped into the game last week and whether it was an ongoing multi-part event all they have said is that it is there for a reason. As and when we get any new answers from Frontier on anything current or odyssey related we'll let you know so make sure you're subscribed to the channel and click the little bell icon so you don't miss anything. A new community goal launched this week that whilst offering again a previously unique reward in the game it also marks a possible change in policy for such rewards from Frontier. Not only will the fully engineered lightweight high capacity and thermal cascade missile rack be gifted as a reward for supplying mined commodities at the end of the CG the event itself will see the unlocking of the module at human technology brokers going forward. The uniquely engineered missile rack from Liz Rider had only previously been released as a one and done reward and it seems now that Frontier have had a change of heart in that regard after all if you were new to the game under the old system this equipment would forever be locked to you giving longer term players an extremely unfair advantage. The CG runs until Thursday next week and details of the community goal are linked below. Far and away the hot topic within the community this week has been that of emergent gameplay and where the line between that gameplay and toxic behaviour sits. There's a really solid read about what's gone on over on the website Polygon and if you're looking for more details I'd urge you to take a look at that but for the uninitiated let me fill in some blanks for you. It seems there's been an organised effort on the Xbox side of the game amongst a small group of experienced players to hoodwink new players into accepting an offer of assistance to gain lucrative rewards from mining. What the offering party fails to disclose however is that once landed on the apparently friendly players fleet carrier they will be transported to a system 800 light years away from populated space with not enough range in their ship to get anywhere without assistance and the only place they can sell their mind resources is the offending carrier vessel which is paying rock bottom prices. With not enough knowledge and experience in the cutthroat galaxy of elite to get themselves out of the situation the victim's gameplay is restricted purely to one of mining for the carrier owner it is to all intents and purposes in game slavery. Precisely how many players have been scammed like this is unknown but Polygon is reporting as many as 15 possibly more. The story however doesn't end there in fact this is where it gets really interesting emergent gameplay you see is a two sided coin whilst there will always be scummy and toxic emergent behaviour from a small minority of players elite has shown itself time and time again to be a game and a community of generous and altogether more altruistic types. You see one of the indentured players reached out to the fuel rats an entirely emergent and player driven organisation of individuals within the galaxy of elite who spend their time rescuing those that have run out of fuel and asked if they had the infrastructure to assist in any way. The fuel rats in turn reached out to the hull seals an equally emergent and altruistic player run organisation that primarily concerns itself with repairing the hull of those stuck out in the black but whilst specialising in hull repairs they also have a habit of performing some more unusual rescues. Likewise the new player initiative an equally emergent player group that dedicates itself to guiding new players to the galaxy of elite dangerous also got wind of the scam. The end result of all this is that the system where the new players were being held hostage has now been populated with multiple fleet carriers and player groups offering an escape route to the enslaved. Frontier developments are aware of the situation and are monitoring but ultimately until their terms of service are broken they won't and I believe shouldn't intervene. Ultimately elite dangerous is an emergent role playing experience some players choose to play traders mercenary and bounty hunters some players choose to play as pirates or explorers and some players choose to play differently. Ultimately the takeaway lesson from this is that you don't land on a carrier that you don't absolutely trust but of course a lot of new players are not going to appreciate the risks when there's still a little green behind the ears. Educating new people to a game like elite is always going to be a tough one and Frontier made mention of publishing a galnet article obviously in universe to help warn players of the threat but of course getting them to read galnet is again a lesson in itself. The important thing and the heartening thing to see is that there are still far more hull seals and fuel rats etc than there are slavers and if elite is art imitating life then take some small comfort from that. Where do you stand on the subject of emergent gameplay and toxic emergent gameplay should the galaxy be allowed to completely run its own course or are you even planning to jump into the rescue effort yourself let us know in the comments below. Links to the organizations involved in the rescue of the individuals affected can also be found in the description below this video. That's it for now thanks very much for watching we'll be back later this week with more videos until then 07 commanders follow the greens on the way out and do keep clear of the toast rack we very much look forward to seeing you next time.