voice today on the show. First time Steve Rothery. Guitars, extraordinaire of Marillian. How's that? Yeah, well, yes. It's a good intro. Talk to Mark Kelly. I've talked to Steve Agarth in the past, but I finally get you on the show. Very excited. A co-founder from the early days. Yes, 44 years this year since I joined the band. Just to give everybody a quick update, Marillian Weekend in Italy, April 28th to 29th, Montreal, that's where I'm at, May 12th to 14th, UK 27th to 28th of May, and Berlin, Germany 23rd to 24th. And I guess my first question to you is, since we're kind of pushing the Montreal angle a little bit, and we'll have a little bit of trivia for everybody. Let's see what's how Steve does on the Montreal trivia questions. I'll toss them in between questions. First question is, what is this relationship that Marillian has had with Montreal? Tell me about the relationship Marillian's had with Montreal over the years. Well, it goes way back to the first time we played there back, I think, in 1984, the spectrum. It's always been an amazing audience. It's always been the highlight of any tour of the States and Canada, really. Incredible.  Yeah, just magical. I mean, we've had so many fantastic shows in Montreal over the years. Was it anything specific that triggered the following in Montreal? Do you remember? Was it the radio play? Was it just the push? Why more so in Montreal then than, let's say, Toronto? I just think maybe the tastes are a little bit more European, maybe. It just seems to be more of a basic understanding of what the band stood for and a passion for what we did. I mean, Toronto is always good as well, but not to the same degree. It seems to be something that Montreal audience seemed to take us to their house. Absolutely. I remember those days. I remember there was a lot of radio play, especially on reel to reel and just the first album. So we were talking to Kingdom Come, the band that sort of had that Led Zeppelin vibe in 84, 85 around there. They got popular. They're always looking for the next Led Zeppelin when Led Zeppelin sort of stopped in 80. So there was like this demand.  I'm not saying you guys sounded like them exactly, but of some sort of mystique, romantic prog? I think there's always going to be a certain sort of person who's looking for something that's just a little bit more interesting than straight ahead rock. And I think that's true for every generation. And I think we came through the tail end of the whole punk new wave movement. And in a way, that did kind of change something in terms of how we presented ourselves. I think there's an energy and an attitude even going way back to the early days that you could tell that we'd been through that. It's about as far from ELPs, Love Island, for example, as you could get. So we had those influences of those early and mid 70s bands and those classic albums, but also get a channel through this maybe additional energy. You look at Fisher's lyrics on the first album, things like He Knows You Know and Forgotten Sons. There's a lot of anger there that you wouldn't really get on most, if you want to call them pure prog records. So I think there was something that set us apart. And I think every generation wants to find and discover something new. And we had quite a young audience in those early days. Maybe their older brothers were kind of into heavier music or whatever. People discovered their own thing and followed those devoted leads since those days. And I will say that I've got the Lux box sets here. Here they are. Can you see that? And I want to tell everybody out there, these are beautiful. And the sound quality is just phenomenal. It's a beautiful sort of record of this era. I've got Fubazi 12 and I'm waiting for Holidays in Eden and Season Z. Yeah, it's like the ultimate versions of those records, really, which I think it's a really worthwhile thing. If that's the one you're going to lead people with. Do you guys own the masters of these? Or is it just strictly for the record company? It's a record company, but we cooperate with them in terms of producing the extra contents. And we've got a halfway decent deal. Nothing compared to the later albums that we own. But just the nature of the beast, really, we're dealing with majors. And you sign a deal in those days in perpetuity. So they own it. Perpetuity is the word. Yeah. So you make the best of that situation. All right. So let's jump to some trivia. You ready? Yeah. Since you're coming to Montreal, I might as well throw out some Montreal trivia. You may know what you may or may not know. Don't feel bad. Don't feel bad at all. Maybe you know all that. All right. What is the name of the mountain in the center of Montreal? I will give you two choices. I will give you two choices. Mont Royal or Mount Everest. I think Montreal is probably the one. Ding, ding, ding. You're doing good. Did you know that? Did you know that answer before? No, I didn't. I mean, it was spent a long time in Montreal over the years, especially with the different weekends. So I've seen a fair amount of the city, but not that. So now you know, there's a mountain right in the middle of Montreal. It's called Mont Royal. That's where they derive the name Montreal. Okay. I got you right. Yeah. Now here's an easy one. I'm going to throw a couple of easy ones at you. Céline Dion is from the greater Montreal. True or false? I know she's Canadian. So I'll say yes. Ding, ding, ding. You got it right. That's two out of two. Great stuff. The last question for now is Montreal an island? True or false? True. You got it. True it is. Montreal is an island. Not in the Caribbean sense, but sort of it is an island that you have. You need to get on some bridges to go onto the island. So yes, the greater the sort of central Montreal is an island. All right. Just going to talk quickly about the new album. Here it is. I know you played it last time when you came into Montreal. I'm not sure if you could give away any spoilers. Are you going to be playing a big part of the album this time around? I mean, you can do the same thing more or less. Well, it will be a very different set, but we will include the new album. I mean, people are absolutely loving it. It gets such a strong response from the fan base. And the Montreal Weekend is the only other three-day event, apart from the first one in Port Zealand. All the rest of these weekends are just two-day events. So yeah, so it's going to be very special. An hour before it starts to pick it up, I think it's probably one of my favorite Merleion albums as it stands today. I just, there's something organic and there's something memorable. And I think it's more melodic this time around. It's a lot more melodic. Yeah. It's just amazing, really. It's like it says how it came together. And Michael and to the producer has to take a lot of credit for having the vision. But then when you add all these different elements in like the choir, and it kind of raises the music up a different level. I mean, I did my guitar solo at the end of Chrome Nightingale before the choirs had been added. So then to hear the final mix with those as well, it's quite emotional, really. It is, especially post-COVID when you listen to it, the lyrics really resonate with sort of the losses that happen and the confusion. No, definitely. That's a subconscious theme that's running throughout, right? Yeah. And especially with the track Care, really. It's an album that could only have been made by living through the pandemic, really. And I think it's, I'm very proud of it. I think it's quite a remarkable album. And the difficulty is going to be trying to follow it with the next one. That is always the case. Yes, always. All right. Tell me about, so Montreal is the only official three-day weekend. What can fans expect? Say somebody wants to go to this weekend. What can they expect if you had to just sort of like to pitch them in 30 seconds? Yeah. Like I say, it's a second three-day event after the first original one in Port Zealand. But it's a full-on marine experience, really. I mean, we have the best audience in the world. So there was a passion and the excitement for the music, I think is very, very rare these days. It's a great live band, a great light show, and it's a party, really, for people who like good music. Are there sort of like afternoon events? I remember last year there was like a book signing during the day. I think it was Mark Kelly who was signing. Yeah. Are there little sort of events that are going on throughout the day or not? I don't know, actually. I haven't seen the timetable. I mean, there's normally like unofficial things that are happening down at the Brutopia pub. So I'm sure there'll be some things that are happening, but I haven't actually had the timetable. Let's get Lucy on the horn. All right. Just quickly, I'm going to be jumping back and forth throughout time. As a big Merlion fan growing up, big Iron Maiden fan growing up, Rod Smallwood was, I guess, your official or non-official consultant in the US back in the day. Tell me about that relationship. And I'll tell you where I'm going with this, because there's a lot of metalheads who are Merlion fans and a lot of Prague fans who are metalhead fans. Absolutely. I think people can enjoy a wide spectrum of music. Yeah, Rod. Rod's a real character. John Arneson brought him along like a consultant manager in that time in the 80s when we were trying to break America. I've known him since those days. I mean, there was a period after we left John Arneson and hit and run management where Sanctuary manages for a year or two. And yeah, he's one of a kind. Was the whole sort of marketing of Rod? Guys, let's also get in crying. Let's also appeal to those hard rockers, metalheads at the time. Yeah, that just came about quite naturally. I think we were maybe partly because of the logo was so distinctive on the first records. You know, you'd see people with denim jackets or leather jackets with the logo written or painted on. I think so there's a very strong identity. And it's, you know, that's one in your own thing, one in your own new band for your generation. But then, you know, we had tracks like Kaley and Laminder in the top of the heavy metal charts, which obviously is about as far from heavy metal as you could get. But it was just rock fans, really, I would say, more than heavy metal fans. Just people who like to hear guitars, who like music with a bit of attitude. And yeah, I think there was quite a crossover especially in the fish years with that kind of audience.  And I know you even guessed it on Irina. I believe it was a guitar song or the tracks. I mean, is the relationship still is it still strong today? Or is it you guys are amical? Yeah, I saw Mick for the first time when we're doing the filming for the documentary to go along with the script for a Justice Tier reissue. I saw him very briefly. It's the first time I've seen him in, I don't know, 10 or 15 years. So there's not really a kind of relationship there as such. You know, it was making the original bass player, Doug Irving, who was marooning or still marooning in those days when I auditioned and joined back in 1979. I always got really well with Mick. It's part of his personality that could be a little bit prickly. But when fish join, it was it was a bit of a clash of egos between the two of them, really, where they both thought of the band as being their bands. And of course, who were wrong? It was my band. But it was just one of those things, you know, Mick, I think, was a little complacent. He wasn't the most natural drummer in the world. You know, he had a certain flair, but he was a very technical player. And we came up against quite a lot of limitations recording the first album script for Justice Tier. And then like this personality conflict between him and Fish got to that point where, you know, there had to be a change, really. Is it true you wrote most of the music on the first few albums? Who? Mick? You. I mean, I was going to say, yes. I'll make you. Yeah. Yeah. I mean, the this parts of script, I wrote more of sections, big sections in the web have got the sun's parts of script itself. Quite a lot of Chelsea Monday, I suppose. Yeah, during the fish years, I probably wrote about 80 to 85% of the music, at least the initial ideas, you know, you then you're arranged and maybe everyone does their thing and then both paint and mark are brilliant to coming up with parts, but the basic structures or the chord changes or the, you know, some of the most important parts I came up with. That changed slightly when, when Steve Hergath joined with more of a sort of like a mixture these days, where some certain people will write certain sections or somebody will write a section and then we kind of develop it. But yeah, it's it's one of the few things I'm really good at. I mean, it must have been somewhat of a relief when Steve Hergath joined. Okay, now all the pressure is not on you, but now you can also flesh out ideas that he has started with. Yeah, absolutely. When we first started playing the Easter idea, I mean, it was just the first part of the song without the guitar solo and the guitar part was actually what the what the keyboards playing on the record. So I kind of brought my own interpretation to that. And then the solo section was something that I improvised that we just happened to record that I could go back and relearn and we could incorporate. So yeah, it's it was a great and it is a great musical chemistry. You know, you've got five very creative people in the band. Sometimes you have more music than you can use, which is a it's a good problem to have. It's a good problem to have. All right, back to trivia. You ready? Yeah, a little bit. Frank Marino of Mahogany Rush is from Montreal, true or false? Uh, true. Yeah, Frank Marino is from Montreal and he still lives here. Right, I did have a Mahogany Rush. I had a Mahogany Rush album, actually, one vinyl. Oh yeah. Is Getty Lee from Rush originally from Montreal, true or false? False. You got it. You're doing great so far. Look at this. Hey, was April Wine formed in Montreal, true or false? Oh, I wouldn't know. True. Nope, it's it's somewhat true. It's actually they formed in Halifax on the East Coast, but then came to Montreal to sort of break the band. Oh, well, I'm not sure if you're an April Wine fan or not. No, not really. Okay. All right. Here we go. Who was not a Montrealer? Who was not a Montrealer? Leonard Cohen, Oscar Peterson, or Alanis Morissette? Not. I'll say it again. Leonard Cohen, Oscar Peterson, the jazz pianist, or Alanis Morissette? Freaky one, huh? I'm going to get it wrong anyway, but I say Alanis Morissette. You got it right. Leonard Cohen, yeah, grew up in Montreal, was raised in Montreal, recorded in Montreal, and of course, he went off to Greater Pastures, passed away. Oscar Peterson from Montreal, from immigrant parents, and he even has like an auditorium named after him in, you know, in the University of Montreal here. Right. I remember he used to have a TV show in the UK, and I remember, yeah, Keith Emerson appearing on it. Oh, yeah. All right. Tell me about Steve Hackett now. Steve Hackett, you're going to do some shows. That's pretty exciting. Yeah. Well, Steve and I have been working on a project together for quite a long time now, which I've tried to move forward recently. We had another session a few months ago based on some music we did together some six years ago on the previous writing session, and I kind of, with my keyboard player from my solo band, Riccardo Romano, did quite a lot of arranging of these ideas. And yeah, I think we've got the basis of a quite an interesting album. Are you going to play some shows together as well? It really depends. I mean, he's so incredibly busy, and my timetable with Marillian keeps me pretty busy. I mean, I sneak in some solo shows. Occasionally, I've got a few throughout Europe in June and September, October this year. But generally speaking, yeah, Marillian, it's a pretty much a full time. I'm in the middle of making three different projects at the moment outside of Marillian, this album with Steve Hackett by Reventulae's Space-Themed Instrumental Album and an album with Thorsten questioning from Tangerine Dream. So I'm keeping busy. Okay. Let's go back to trivia. French fries with gravy and curd cheese is called Putin or Putin. Oh, yeah, this could go very, very wrong. Putin or Putin? Putin. You got it, my friend. It's a good, it's a good choice. It's a good answer. Is Montreal best known for Philly steaks, Philly cheese steaks or bagels? Well, I don't think I've had either of those. So that's a really difficult question. Steve, Steve, Steve, Steve, you haven't had a Montreal bagel? Yeah. There's a hint right there. Oh, well, I think it's going to be bagels. So Montreal is known for its bagels. So when you come to Montreal, make sure to pick up some bagels. Will do. They're iconic. If you like bagels, maybe you don't like bagels. Love bagels. Yeah, I'll be there for a week. So make sure I will buy one of them. All right. Is Montreal best known for smoked meat or smoked meat? Is Montreal best known for smoked meat or smoked meat? Smoked meat. You got it. Everybody gets that wrong even in Montreal. People say smoked meat. It's not smoked meat. It's smoked. That's the proper English. That's why I have an Englishman on. Yeah. Here's one more. Here's the last one. True or false? The Montreal flag, the official flag of Montreal represents the English, the French, the Aboriginals, the Scottish and the Irish as the sort of founders of the city who built the city up. True or false? False? True. True? Well, Montreal flag has the English, what's the symbol of the English? Union Jack. Yes. No, not the Union Jack. Not the Union Jack. That's the British. Oh, the England. Right. Right. The shield. The flower. The rose. The rose. The rose. The rose. See, I even forgot. The French Fleur de Lis. The Aboriginal, I think it's a pine tree. The Scottish and of course the Irish, what they're for leaf clover. So those are the pictures on the Montreal flag. So when you pass by Montreal, take a look at the flag and say, wow, I didn't know that. That's pretty cool. Yeah. Yeah. We'll check that out when we land next time. All right. Let's get back to it. What about music for a new album? Are you guys, are you just tossing ideas around, thinking about it? Yeah. You know, it's a very different state of mind when you turn your focus to writing. So at the moment, we're just in performing mode, you know, it's like, to do these brilliant weekends, you have to keep between six and seven hours of music in your head. It doesn't leave much space to come up with new things. Having said that, I mean, there was some ideas from the last album that we didn't use that we might well revisit. There's one complete song that was great, but just wasn't didn't fit in with with the rest of the stuff for the for the record. So we've got probably going to be spending most of 2024 writing and then probably start recording towards the end of it, hopefully for a release in 2025. But you know, when you spend six to eight months of the year rehearsing and then playing these weekends around the world, it doesn't leave much time to do anything else. Yeah. All right. Naming your favorite solo in the fish era and your favorite solo in the Steve Hogarth era? In the fish era, probably incubus. That's the first solo I've had. I felt like I really kind of defined what it was I wanted to do on the guitar. And so many solos were the hate era, but probably the last solo in this strange engine. Always an amazing response. Yeah. What about name your favorite album in the fish era and your name, your favorite album in the Steve Hogarth era, which is probably a little more difficult because there's a lot more albums there. I get that. Yeah. Fish era, I'd say probably clutch in its rows. So the Steve Hogarth era is almost impossible. But I'd say probably afraid of sunlight. I think it's a great collection of very different songs. Yeah. I would agree with you, too. I mean, I would say that afraid of sunlight in this album are like on par with each other. Yeah. No, I kind of go along with that. And it had that same vibe. Is there anything you want to say about the upcoming shows that I didn't actually ask you? No, not really, I think. I would just look really looking forward to it. It's always such a pleasure to visit Montreal and try and explore the city and do what you can. You get over the jet lag as soon as possible so you can go off exploring. Okay. So now you know about the bagels. You know about the smoked meat. You know about the flag. You know about who came from here as musicians. Now you're going to look for all these little things. Yeah. Yeah. And it's a real pleasure to walk around. You know, there's loads of interesting parts I find to the city, not just the old part, but you know, some of the other places. I can't even remember the names of them because my daughter took us around a few places. But yeah, really, really interesting. All right. And on that note, Steve, thank you so much. Look forward to seeing you guys in Montreal watching the shows. Much appreciated. Thank you for your time. Cheers. Good speechy.


Hello and welcome to a new lab for our STM42C0 MOOC. In this lab, we will learn how to create a RTOS, so real-time operating system application, on a STM42C0 using ST development tools and Microsoft Azure RTOS FredX, which is included in our STM42Cube environment. The purpose of this lab is to create a simple project using STM42CubeIE and Azure RTOS FredX. We will be using the STM42C031 nuclear board and we're going to create an application that will read the user button state and work with that to turn on the LED and send the messages on the UART. So we will have different threads running using the RTOS FredX. We will follow the steps below. First, create a new project. Second, select a part number, STM42C0 part number. Then do the STM42CubeMX settings configuration part. Then do the pinout, the pin configurations. And then finally, we will add some code, you know, to add our application code. First, let me give you a little bit of introduction to our STM42Cube software suite, ecosystem or environment. Starting from the left, we have the software tools including the STM42CubeMX, the STM42CubeID, so that's what we have been using in this MOOC so far. And we're also going to use this, so this is our ID for this lab. But we also have the STM42Cube programmer and the STM42Cube monitor. In the center, we have the embedded software where we offer our STM42CubeMCU packages, including the drivers, so the HAL and the low level drivers that we have seen previously in this MOOC. Then we have the middleware and finally some application code examples that we provide. For the STM42C0, the middleware integrates all Microsoft Azure RTOS suite for free. This includes Azure RTOS FedEx, so for real time operating system. Azure RTOS FileX, so this is for file system. And for some part numbers of STM42 that includes Ethernet and USB peripherals, we also include Azure RTOS NetEx and Azure RTOS USBX. Now we can start the lab. So you know these steps very well by now. So first we're going to create a new project under STM42CubeID. We're going to select the STM42C031C6T6, so this is the one that is used on our nuclear board, so the Nucleo C031. Okay, let's create a new project. So make sure all your previous projects are closed and now we can create a new project for this lab. So you know the steps. Now in the STM42 project for the MCU selector, we'll select as before the STM42C031C6T6. So that's the one that is included here in the nuclear board. So we'll select that and click next.  So for example I'm calling it STM42C0 underscore RTOS and then click finish. The tool might ask you to change perspective to open the device configuration tool. So if this is the case, then press yes. This will bring us to the STM42CubeMX settings. So this is where graphically you can configure your project. First in the system core we will select the sys, so for system, so sys and you're going to select a different time source than the sys stick. So because we're using RTOS applications, so we will use a timer for the hull, so for the cube library. So select for example the timer 16. So this is the STM42CubeMX part of the project in the pinout configuration tab. Under system core we will select for sys, so for system and then for the time base source we'll select, instead of sys stick we'll select a timer, so timer 16. Secondly, so under connectivity we will enable the user2. So this is in order to get some user messages that will be part of our application. So same thing, on our nuclear bomb. So now, under connectivity, so look for connectivity here, look for user2 and we will enable it in asynchronous mode. Last but not least, we will go into the middleware section and then open middleware, select fredex and then enable core. So next to core there is a checkbox, enable it. Enable the azure auto fredex feature in your project. Scroll down all the way here, middleware so expand it select fredex and click here on core. So this will import all the files necessary for your auto application using fredex. Now we can take care of the pin configuration. So for example we want to use the user button so we configure PC13 that is connected to the user button as a GPIO EXTI-13 so external interrupt mode so like we did in a previous lab. So in the pinard view right there we're going to expand a little bit look for PC13 so it's located here and we're going to configure it as GPIO EXTI-13 so external interrupt line 13. Now we will configure the IO that is connected to the LED as output push-pull so to drive the LED high or low. So the IO on the board is pf5 so connected to the circuit to turn on the LED or turn it off. So we configure it as GPIO output pf5 so we will add some labels to the two IO's we configured so PC13 will label it to user button and pf5 will give a user label as LED to enter a user label you're going to right click on the pin so here enter user label so for PC13 we will enter user button so to be compatible you make sure that you put user underscore button uppercase B4 button and then enter and then now we're going to add another user label for pf5 which is connected to the LED and we'll name it LED uppercase now we can configure the NVIC so the interrupt controller so to do this you can go to NVIC from the system core also from the system view the following window will pop up and display a warning so displaying the following so if interrupts handler call RTOS functions please make sure their preemption priorities are lower so numerically higher than the highest sys call interrupt priority so this is something to keep in mind so in our case we don't have any functions or RTOS functions called so we won't have the problem but you know that's something to remember so press ok ok so the NVIC you can find it here so in the system core or also in the system view so we open it here so this is the pop up message that I was telling you about and press ok in the NVIC enable the EXI line 4 to 15 so this is the interrupt for the EXI line 13 which is remember the user button so PC13 connected as external interrupt that we will use for the user button ok so in the NVIC let's expand it a little bit to see what's going on so we want to enable the EXI line 4 to 15 interrupts so this is for the user button now we can generate the code so remember the little icon like this with a gear or you can also press ok or just save your project so that will ask you to generate the code and then press yes ok we will generate the code so using this little icon there and change perspective yes we will enter the C and C press perspective where we are going to add some code now it's time to code so this is the first view of your project so as you can see so this is your project right here project explorer so you see all the different folders of your projects and in core source you will see that you already have some new files with you know the azure auto support right there and then we will see that in the middle where you also have some additional files and directories you can also notice that in your main.c you already have an include for app underscore fredex.h so this is your project right here so the user files are going to be here so we are going to be modifying or adding code in main.c and also app underscore fredex.c now I want it also to show you in the middleware so where are the fredex files so all of them are right here so this is included in your project first we are going to add some code to redirect the printf to the uart2 so we did that in a previous lab so if you want to do to know a little bit more about the process you can review the MOOC lab about the printf so we give more details about how to redirect the printf to a uart so uart2 in this case and we are going to add the code in the user code 0 section so remember to add the code within this user code begin and end so that it doesn't get deleted when you regenerate the code from the stm5 to kubemax part of the project so we are going to add this code in the main.c in the user code begin 0 section same as before, so for the code to be added you can find it in the description of the video right here and you can just copy and paste or otherwise if you want to type it you can do that also so this is the code here and in my case I will just copy and paste from the description of the video so in main.c scroll down and look for the user code 0 so this is the section we are going to add the code to redirect the printf to the uart2 that we configured previously so this is done now we can open app underscore fredex.c to add the following code so first we are going to add some includes so include stdiu.h and also include main.h ok I am going to save main.c and now I am going to open app underscore fredex.c which is located into core and source so double click on it and first we are going to add the includes so right here in this section right there includes please add the stdiu.h and also main.h now we can add the size so the stack size for the three different freds we are going to use and also for the different queues we are going to use in this example so in the private defined in the user code pd section please add the different stack size and also the queue size so let's keep on coding and adding some code so in this code section here we are going to add some code to create the freds create the queues create the variables and functions prototypes for the code so two parts first in the private variables in the user code pd section please add the following so this will define the stack the queues so the size of the queues that we defined previously and also for the stack size and then we define some pointers for the freds and also for the queues step 2 of this task is to go to the function prototypes and add the three different function prototypes for the three different freds now let's create the threads needed to use the button status to control the led and the messages sent via uart so using printf so scroll down now and we are looking for this section here so which is app underscore fredex underscore init so in the function app underscore fredex underscore init so in this section let's add this code so to create the queues and create the threads so we're going to create two different queues to send messages so for the button status and the led status and three different freds one for the button status the other one for the led action and the third one for led status almost there so now what we're going to do is add some code to create the thread functions to work with the button, led and the uart for the printf so we're going to add that in the user code one section and we're going to add basically the three different threads that we're going to create right here so this is the code for example we're going to start with adding the code for the button status and then we'll move on to the two other tasks or threads so in the user code one section at the end of the file so still in app underscore fredex.c in this section we're going to add the three different functions for the three different threads so let's start by the button status so this is the first function to be added here at this location now we're going to add the second function so led action so still in the user code one section so right after this first function we're going to add the second one right here so this is led action now we're just missing one to be added and last part finally we made it let's add the last function which is led status we can now have a look at the code that we added especially the different threads so different tasks so here let's start with the button status so what do we do in the while loop, so infinite loop we put a delay and then we're going to read basically the user button depending on the status of the user button that we're going to read we're going to set or reset a variable right there and we'll send it send using a Q, so a message Q so txq send we'll send the message to another task so this is the second task here where we're going to receive the message that was sent by the first task depending on the message we're going to turn on the led or turn it off and then at the end of the message using Q1 this time where we send a new message to another task and so this is the last task and depending on the message we're going basically to display the leds on or the leds off alright, so now it's time to test our code so we're going to build it and we're going to run the code it's time for our debug session now let's build the code first we're going to build the code so remember the little icon like that the hammer to build the code or you can do project build all make sure we have no errors and no warnings let's build the code pressing the icon here and we'll wait for the end so it might take more time on your machine so you can pause the video if needed so zero errors zero warnings so that's great, good starts let's continue now we can enter the debug so make sure your board is connected of course and you can do run debug as stm42 c++ application or directly click on this little icon like the green bug so we can now click on this little icon you can see it here so this is to enter the debug session we're going to press ok now we're going to load the code and also change a perspective so that's coming here we switch and now we are ready to execute our code so to execute the code remember resume ok, so at this point we talk about that in a previous lab so I'm going to go fast on this and you might already have a console that is being created that you can select otherwise I will show you again here how to create a new you know like terminal a serial port, you know terminal within stm32 cube ID so those are the steps first you're going to find shell console from here, from this menu then you're going to create a serial port new or select a previous one if you add one but in this case we create a new one ok select the parameters so first you will give the connection name like here we're going to give a name like terminal one select the proper serial port that is associated to dstlink virtual comports so in this case this is com18 in this example and for the parameters we're going to use 115-200 for the board rate, data size 8 parity none and one subit then click finish to complete the creation of the terminal we're going to select the encoding so for example here I'm selecting utf8 but previously I selected iso which also works so there's no issue there and then just press ok ok so let's create this terminal so let's find the icon that we're talking about it's located here in the bottom right here expand it go to command shell console so this is where we can create our connection type so first select serial port so in this case I had a previous one that was created but I will show you how to create a new one so click on new then give a name to your project so we said terminal one and then select the proper comports so if you're not sure which one go to your device manager and make sure you select the proper one so in my case it's com18 and then we keep the rest by default then click finish select we said we tried a new one so utf8 that also works iso also works and then press ok now I can test my code so let's press this user button which is the blue one on your board press it press press press as long as you press it's going to turn the led on you release turn it off release turn it off and you have ofc the led also that changes so the green led connected to pf5 that changes ok so it works perfectly fine so we have a good example about Artos application so ofc of course you know it doesn't enter Il y a des détails sur comment utiliser Fredx, donc il y a plus. Nous avons des autres vidéos de collection sur notre channel STM32, où nous parlons de plus de détails sur comment utiliser les Fredx. Mais ici, je veux juste vous donner une idée de comment vous pouvez créer, facilement, comme une application Arthos sur votre STM42 C0 avec notre outil. Vous pouvez maintenant arrêter l'exécution, donc cliquez sur cet icon là-bas, le red square, et fermez votre projet. Alors cliquez, fermez le projet, et nous sommes prêts. Merci beaucoup d'avoir regardé.


Things are finally heating up at Brainerd International Raceway as the first day of qualifying began for this weekend's races. Start things off with the top fuel division, Antron Brown, the top qualifier of the day with a 3.789. He won last week looking for back-to-back wins. The funny car division, the top qualifier, was Robert Height, finishes with 3.971, wins both heats to get six points in the standings. In the pro stock, Erica Enders, who's already won here twice, finishes first with 6.609, seeking her first overall qualifying position since 2015. And in the pro stock motorcycle division, fastest speed in the division in the racetrack's history goes to Matt Smith, qualifies in first with 6.852. These racers were looked to hold on after tomorrow's seats, but a good start to the weekend. All the points are going to matter at the end of the game, so we're really excited to be number one, even though it's just for Friday night, it's okay, we'll try to hang on to it tomorrow. You have a lot more confidence with your team, your race car, going into Sunday if you made four good qualifying runs. So that's the goal of tomorrow. We went through our bumps and bruises, and the thing about it is that's why you go through the struggle, so you have days like this. We normally run good here in this track. It's kind of where I live, it's kind of the same altitude, barometer, so I make a lot of dyno pulls so I know how to tune for this kind of air. If you enjoyed this segment of Lakeland News, please consider making a tax-deductible contribution to Lakeland PBS.


I've always thought we'll stay at the table. Yeah, that's what you're going to end up with. Or one of the guys does all of it. Good. Alright. Condition one weapon. Pull the bolt to the rear, place the weapon on safe. I'm going to grab the right one now. Alright, go ahead and give me the... To get on target! Work on the two below them. You're going to work your way. You taught the ball.


Okay. Hello, everyone. Thanks for joining. I know it's Friday, so I appreciate you are here My name is Vojtek Tyczyński. I work in Google. I'm The TL of 6k ability and together with Marcel siemba Who is one of the chairs of six Calibur that we are going to present like the six Calibur the update today Okay, so let's start so What we are actually doing what the six Calibur the is actually doing so There are basically five main aspects of things we are doing which kind of correspond to sub projects, but In terms of like six Calibur the that doesn't really own any Non-tests related code like sub project is some sub projects are somewhat somewhat fluid here, so So yeah, so the first thing that we are doing is actually defining what does scalability really mean for Kubernetes? it it both means like defining Defining well What does it actually mean but also like where we are actually having like the core principle for any scalability related efforts is to Focus on actual real life Scenarios and real life needs like optimization for the sake of optimization doesn't really make sense because it's usually With some exceptions, but usually it's like complicates the system So we should be only focusing on things that are really needed for someone The next thing that is like strictly related to that is like Once we have those goals like we need to actually execute towards those so actually driving and Ensuring that like the actual improvements that are needed to get to those goals are Are something that we are working on This doesn't really mean in many cases that we are doing the improvements if if those are fitting into Individuals six like I don't know signals or CK behind machinery or whatever. We are trying to To work with those six and ensure that those will be doing that but we are often also contributing to those themselves and for any Cross-seq Improvements than to work a bunch of those like over the past years. We are we are usually coordinating those across those six The next thing is Ensuring or checking where we actually are like we know where we would like to be based on the first item But we don't really often know where exactly we are now so Monitoring and measuring where exactly we are is it's pretty critical to Understand how far we are from our goals. And is there anything is there really any work that we have to do in this area? The next item that we're just strictly related to that is Is ensuring that we are not regressing so once we reach certain level of scalability We need to ensure that That we actually stay at that level. It's it's pretty pretty easy with scalability to regress Because like every every new feature is or every new change in the system is often If not well thought through it's it's often possible to easily regress the system and finally We need to ensure that scalability is is not the job for like a very small group of of people like Sitting in the corner, but it's actually a job for everyone like similarly to Reliability or security or whatever like when you are designing your Designing and implementing your your feature you need to be thinking about like scalability on your own like we can't like it can be We can't ensure scalability If the overall community won't be thinking about that so we actually made a very very long journey and very successful journey I would say since the since the early beginning of kubernetes when they were pretty much like Two or three of us like thinking about scalability now Scalability is actually an inherent part for pretty much every single cap Which is like I hope that you all know what kept this. It's like our design doc more or less people are thinking about scalability, but Not everyone knows exactly how to do it They know they should be thinking about it So this this item is actually about ensuring that when they reach out to us like we have like best practices we We can recommend what they should be doing in that situation and so on and so on Okay, I'm one more thing probably worth mentioning is that like we shouldn't be confusing it or it's often confused like sick out six scalability is often confused or mixed with sick out of scaling like auto scaling is about Scaling either your size of the cluster like adding nodes or removing nodes or Scaling your number of pods or or pods in general either horizontally or vertically scalability is about like the Amount of stuff that you that you can do our amount of for example, like how big your cluster is or how many How big services you can handle in a single cluster and so on and so on Okay, so What is really scalability in terms of Kubernetes so As I mentioned like you should all we should always be focused on on actual user needs So when you ask users if they want scalability of the if they want this cluster to skate the answer is obvious Like they are they are all saying yes, of course, but if you know if you ask them like what does it really mean? The answer is often like I don't know Or it's even more it's often also. I don't care because they don't want to like understand all the details of the system They want us to handle that so We need to define it our on our own So like the first approximation that we did like in early 2015 Is we approximate its scalability with like size of the cluster so number of nodes basically so when I first started looking into that like in February 2015 or something like that like that 25 node cluster was basically blowing up and over time we are basically improving that like Starting from like support for hundred nodes in 1.0 reaching like 5,000 nodes In a steps like in in 1.6 release and we didn't really go higher than that since then So now you are now you are probably thinking like if we did anything like in the last like five years and yes, we did we did quite a lot because like Scalability is like actually much more than than like the size of the cluster or number of nodes Basically scalability is like a multi-dimensional Multi-dimensional or scalability in Kubernetes is a might multi-dimensional problem where like things like number of services number of pods number of Endpoints in a service number of persistent volumes and so on like the all they all actually matter for scalability So we introduce this concept of like scalability envelope Which is basically saying that if your Cluster within the same with within each of those they mention is actually fitting into that scalability envelope that means that like Your cluster has like scales or your cluster will be happy basically so What does it really mean that the like your cluster skate or is it happy? So we are building or we are defining that like based on like two main concepts SLI SLI is an SLO so SLI is like silver service level indicator as a lowest service level objective You can conceptually think about them ours like SLI being a metric and that's a low being like a metric and with threshold It's actually much more subtle, but like conceptually. It's it's basically It's basically that so The cloud we are saying that like the cluster is happy if all those scalability SLOs are basically satisfied So more or less like all the metrics are within that the threshold that we that we define. So We don't have much time and we don't have like Enough time to talk like in very details about like SLIs and SLOs so If you are interested I had to talk purely in that topic or purely about that topic and like Barcelona You've gone like so we can probably find find that and then in YouTube if you want so just very briefly like we have like Six main SLOs that we are currently measuring SLIs and SLOs They have like subvarious. Some of them have some sub variants, but like Conceptually we have six of them like the first two are with us like since the very beginning The the the latter four were added over time So as you can see like we don't have like a super large coverage There are different pieces of system that aren't really covered like I mean some of them are covered Implicitly like for example like scheduling latency It's actually part of pot startup time or pot startup latency. So There is there's more covered like Implicitly then then then then then from what looks it's from the one from from how it looks like from the first glance, but We are still we still have a bunch of like holsters. So it's one of the things that We want to invest for quite some time and we we never like have time for that So if you are interested like it's it's definitely one of the areas that we would We would benefit from your health So let's take maybe one one example and look into a little bit more detail I'm not going to to to read it and I I don't even expect you to read it like the main point is that Even though like the conceptually the SLI should be Are or we are trying to make them very simple and that like high level. So basically for mutating API calls we can say that like the What we want to achieve is that like the Mutate like the 99% of mutating API calls is finishing one in one second And this is more or less was written in the slide But we need to be super precise in this allows to ensure that the way we understand it and the way we measure it It's like exactly how you as a user also understand it It's it's like we had a bunch of cases or I've heard about other cases also from outside Kubernetes were the the fact that like The ones who this define the SLO Understood it differently than the actual users was was causing a lot of friction. So we need to be super precise here Okay, so Basically Once once we have the like once we defined like all those SLOs users know what to expect where What to expect from the system or how the system will be behaving if they are within the scalability envelope, but They also like or maybe primarily in many cases. They want to know like what the scalability envelope Or how how large it is or how far they can go in the dimension They are actually interested in so Computing it precisely it's like super hard or maybe even impossible So we are not trying even to do that. We are fortunately able to like approximate it pretty well by by some By providing like a certain thresholds in many dimension in all of the dimensions It it's if you if you take a combination of those It's It's not actually the whole whole envelope It's possible to go much farther in in certain dimensions if you go lower in other dimensions but we want to provide something that is That is easily consumable for everyone and for the most sophisticated Most sophisticated users we can work for them and explain them better now like if they can actually go farther with that Okay, and with that I'm passing the microphone to Marcel we'll be talking about other stuff Thank you. So basically right now we know what scalability means what kind of SLOs do we care about but the question is like How do we measure it? How we ensure that this as these SLOs are actually Satisfied in Kubernetes. So we will go through scalability testing infrastructure What kind of tools we use and basically how we ensure that Kubernetes is scalable So our main tool that we use every day is cluster load loader 2 You can think of it as bring your own cloud bring your own basically kind of similar to like regular deployments that you that you do for Kubernetes and You can think of it as you specify kind of states in which you want to have your Cluster in for example, let's say that you want to make sure that you can run 200,000 pots in your cluster then what you do is you specify this state as for example You create 1,000 deployments with 200 pots each And then you can specify even more states like okay once I have those 200,000 pots, let's say I want to delete half of them and When you have those states what you can do is you can specify how you transition between those states because obviously if you create 1,000 deployments with 200,000 pots in total then Most likely something will break but what you can do is basically say okay I want to create one deployment per 10 seconds or maybe you want to specify that You want to create all those 1,000 deployments within 10 minutes or one hour so you can specify all of those transitions between states and Then on top of that once you do it what you can do is Measure measure those as laws that we mentioned so you specify that for example you care about API Latency or pod start up latency you care that the pod start up latency will be within 10 seconds and so on and except for that we have bunch of other extra features that allow us to monitor observe and Test it basically you can find all of that on our documentation for cluster loader 2 and if you ever want to Scale test Kubernetes. I strongly recommend to use this tool But of course as you may imagine running 5,000 cluster node is pretty expensive and In open source what we do is actually we run 5,000 nodes every day to test for scalability regressions But this doesn't give us like really good observability because Let's imagine that you know there is one day and there are 50 PRs merged into Kubernetes and we see some regression This would be quite hard to kind of like see which kind of PRs are actually breaking the Kubernetes But fortunately we have cubemark and cubemark is simulation of the cluster instead of running 5,000 nodes what you can do is just run like 80 nodes and Until on those nodes you can schedule pods for example what we call whole nodes and whole nodes is something that Simulates regular node But it doesn't actually run the pods so you can think of it as okay regular quiblet Just takes the pod and it's running the container But whole node just reports back to API server. I'm running the container, but it's not actually running the container so whole node consists of actually three parts one is whole cubit and We also have whole cube proxy because cube proxy is actually One of the parts of Kubernetes that is putting quite a lot of pressure on the API server and Kubernetes master And except for that we have also hollow node Problem detector. So with this kind of setup what you can do is with 600 CPUs you can test or simulate 5,000 node cluster Yeah, but then you might ask okay, so how how do you actually run those 5,000 hollow nodes? It's not easy right. So what we do is we actually We actually create second cluster. So we have one Kubernetes cluster that is responsible for For just running those hollow nodes And then those whole nodes connect to the actual Kubernetes master that we are scale testing with cluster loader 2 Yeah, except for that what we do is here You can see our great tool perv dash as you can see it's quite outdated But it's like one of the most useful tools that we have in six culability and here you can see example that okay, this is 5,000 CI test that we constantly run for for Kubernetes and we measure here pod startup Latency and you can see like 99 percentile 50 percentile and so on and based on that We can detect some possible regressions because as a law says that okay The pod startup latency 99 percentile needs to be below five seconds But we are still unhappy when you know the 99 percentile was three seconds And then it bumped to four seconds for example So we we see it in the perv dash and based on that we can still debug it and and see it Then of course we have grafana.  I actually recommend to check it out and Those dashboards are in our our repository and you can use it for your own cluster if you want And there is like bunch of like really cool graphs that allow you to to check like API server latency But scheduling and and all of that stuff Then we also have profiling so when you are running cluster loader 2 what happens is that? It's not only like gathering those Prometheus metrics, but also It's getting the profiling from the API server for example and based on this profiling What we usually do is we go through it and see what kind of parts of API server is actually consuming most of the CPU or memory and Based on that we can plan and iterate on improvements to API server So now okay I talked a little bit about our infrastructure what kind of tools we use for for scalability testing and now we can go back to Scalability test what kind of test we actually do run and What you can see in our test grid basically so We have periodic tests CA tests and we split them into two categories One is release blocking and one is non-release blocking. So release blocking tests are the ones that you know, there is new release of Kubernetes and We see that okay the scalability doesn't look great Then we say okay We just need to stop the release of Kubernetes and debug it what what happened basically And we have performance test with 100 nodes performance test with 5,000 nodes and correctness test that makes sure that Regular features in Kubernetes work at scale as well Except for that we have non-release blocking which are kind of like more informative for us So kubemark is one of these examples that I talked about But except for that we have storage go on benchmarking different type of but one of my favorites is actually going so with going we actually saw like multiple times that You know going change the compiler changed and it totally broke Kubernetes So we have one dedicated test just for just for testing compiler of the going Which is basically running fixed version of Kubernetes? But we are just changing the go on compiler and If you are a contributor then probably you saw our pre-submits We have 100 nodes pre-submit test that it's running for each PR that Someone is trying to merge to Kubernetes master And this is like early warning that something might be broken basically and It protects basic Kubernetes from like super super big regressions So yeah, now let's get to protecting scalability of Kubernetes. So This is our test grid. You can check it out. It's It's in our yeah, you know, like basically the test grid that all the tests are there And you can find like six scalability test grid and and we test also release branches old ones and To make sure that you know if there are some cherry peaks to 122 123 then they are also not breaking old versions of Kubernetes as wait I mentioned before scalability is very sensitive and What happens is that there are so many things that can break scalability of Kubernetes To name a few we saw as I mentioned before going that compiler changes Can break but also call operating system controllers and API machinery meaning like API server schedule scheduler at CD and cubit basically everywhere So what we do is we try to Try out those issues debug them and once we know that okay the fault is because of the change in scheduler or going What we do is we reach out to those six and try to to help them fix those issues and Sometimes we just fix them by ourselves So I will give you a few examples of like really cool regressions that we recently debug So one was pod startup latency and the idea was that okay since like 120 We've been heavily investing in Priority and furnace and along the way there was one regression that Significantly increased the pod startup latency. So we were the ones that were debugging and the root cause was actually quite simple. So we started supporting watches in priority and furnace and The number of go routines that one watch was requiring was actually doubled. So instead of like a having 1150,000 of go routines we had 300,000 go routines and at this point Scalability just degraded for for pod startup latency There's also like API call latency regression, which was also connected to priority and furnace. This actually was This actually basically increased the API call latency for all the possible resources And so we were also debugging it and fixing there is pretty cool at debugging in this issue that you can you can find on github So except for protecting from scalability regressions, we are also driving scalability improvements and recently we were helping with the migration of Going to 118 and then we also help with implementing efficient watch resumption or Immutable secrets like secrets are actually one of those things in a cluster that can put quite a lot of pressure on API server so if you are deploying your workloads and And let's say that you are using secrets then maybe you should consider using immutable secrets to just make your Kubernetes API reliable More reliable and except for that We also work heavily on priority and furnace which further increases their ability of Kubernetes so If you want to get involved There are a bunch of links. You can attend our public meetings. They are on Thursday 17 30 and Yeah, join our slack channel if you have any questions Our mailing list you can can always reach out to us and we are happy to help If you are developing new features, then we can help you with reviewing it Or if you have any issues, then we can try to help you with debugging those issues and if you want to get involved there are some issues that are marked as help wanted and Basically getting started and so if you are interested in our tooling then you can help us with developing tooling If you are interested in regressions, you can help us with debugging reg regressions So thank you and now it's time for Q&A so nowadays there are Sometimes more CRDs and controllers in a cluster than than workload or or anything. Yes So how do you what do you think about this and how do you consider it? Yes, I Think there are different aspects of that like well well designed controllers to see are like based on CRDs Are not really a problem I mean CRDs are a little bit more expensive than like built-in APIs because because of not using proto buffs for example and using JSON and so on but like that's not a core of the problem like we It's fine. Like the biggest problems that we see are the like Note but note oriented controllers So that like the demo sets more or less that are like watching or even worse listing in some cases like a bunch of state From many notes. So that is really what is causing the problem. So I think that our Main problem is not the fact that we have CRDs and controllers. It's the fact that like Still there are people that are Designing they controllers in like in a inefficient way. I would say I Think we would like to get to like improve like the efficiency of proto buffs in general like the the discussions about supporting proto buffs for CRDs were happening since I know four years or something. It's just like big thing with not High enough priority at this point. Okay. Thanks. Hi my question is So, where are the trade-offs or focuses in terms of improving scalability? Or where are the red lines that you would not like to cross More concretely, for example, have you considered Rewriting some of the components in another language or or switching out very important Important component or deprecating a feature that impacts scalability a lot, but a lot of people rely on that Yes, so Good question. So I Think the first example that you made for example rewriting components something that we really would like to avoid I don't think we want to do that. I mean, especially in a different language. I think we want to like consistency It's fairly important like for the project as a whole like for us as a community and so on like we we don't want to Diverge too much like between components. So I think it's it's it's probably one of those lines that we don't want to cross Re-designing individual components. I would treat it as a last resort, but I wouldn't exclude it like for example networking Cig network is actually considering or they are they are thinking and there's even capital is like Not yet approved, but like active on like how to redesign cube proxy to make it a little bit more efficient So like those kind of things is something that we Definitely consider about like it should go into like individual six like that The requirements should be coming from us, but like it shouldn't be us doing the work It should be that sick driving the work and to rewrite that controller and and ask me like like in Coordination with us and like us helping with that, but like driven by them more or less. I would say Sorry, I forgot the last part of your question. I think there was something more The last part was about deprecating features. Oh, yeah, I think The goal is to actually uncover the regressions or uncover the Unscalable things like as early as possible. So like in general like purely from scalability like wearing my scalability hat like Yes, I would like there are some things that I would like to deprecate and I would like to get rid Wearing more my like production readiness hat and like I'd like all those like higher level things We really don't want to do that. Like we really don't want to break users. So What we are trying to do is we are trying to Introduce a different way of doing stuff or the more efficient way of doing stack for example, like Podante affinity is one of those features like of one of those like scheduler features that doesn't really scale well And it's causing a lot of troubles for scheduler. We introduced like the feature that is called What topology spread if I remember correctly that is kind of doing a very similar job or like for majority of cases So we are trying to steer people towards like more scalable regressions by not by Disallowing them to run to use that the old ones but rather about like giving them a carrot to To use those new ones or or better one or however you call it. There are exceptions I think we recently deprecated like the self-link field That was part of like like every object used to have like a self-link that was basically like self-link And we actually deprecated it. It's no longer set anymore but That was done based on like significant research and and the outcome that no one is really using it for anything useful that and kind of like all of the cases were That we are aware in many different repos Can easily be replaced with already existing stuff and that are not based on self-link. So That's the only example that I remember in the last like two three years where we did that And we generally would really like to avoid it as a project Sorry, so I have two questions. Firstly, I think Way at the start you mentioned you have some documented design principles for other maintainers so Or maybe I misunderstood so if if as a as a component maintainer in in Kubernetes I I want to go and read the You know the cliff notes. What what should I be thinking about? When making design changes to my component, do you do you have a general principles doc? We are missing it a little bit like it's there are some pieces some small pieces here and there written, but I think One of the things which is we are missing like this go-to page that you can go and like read those Seven things that you should first think about it. And if you are interested then live in more detail, let's shut but We are actually missing that really. Yeah, but also like if you are Developing some component then I would recommend like just adding it to to our Load test so it will be just covered by our regular CIT tests, which can also be helpful for you If it's possible of course because it's not not always possible. I maintain cloud components, so Normally not but Okay So my other one was was kind of related to the previous question. So I was kind of interested if you could you've described Diagnosing a pod latency issue and the root cause was I think you said a change to double the number of go-routines on watches. Yeah. Yeah, so Presumably somebody had a reason for doubling the number of go-routines on watches. It was just like, you know programming back basically that was introduced Okay, you know and still like the SLO was fine, right? So we didn't see it at first but using the perv dash where we can see like the changes over the time We were able to spot that, you know 99th percentile of pod start out latency increase for like three seconds to four seconds and based on that We were able to kind of like, you know, see that okay It was within this time that the pod start of latency increased then we went through a few PRs and we picked this one that it's most likely this one and Then we work with Vojtek to fix it. Yes, maybe to tweak the answer. I wouldn't because I'm the one responsible for the I Wouldn't say it was a bug. It was basically a Think like how to like when you are like implementing a feature or designing a feature you want to get to like To production as soon as possible. So There are like there are some shortcuts that you are sometimes kind of like taking and it was like kind of like underwear shortcut that like We like the tests were passing. So we didn't really pay that much attention but but yeah, like it was basically Don't over optimise if it's not really not really needed. It appeared that it's actually needed. So so we like fix that but Okay, so yeah, you didn't you didn't have to ask somebody yourself in this case to remove a feature or redesign something Yeah, it's fortunately it was relatively Small change. So it's it wasn't like really like conceptually like We are paying like we are trying to pay as much attention as possible to the design itself And once the design looks scalable We should be pretty convinced that like the implementation is possible to do in scalable way And like even if the first attempt is not maybe scalable then you you can re-implement it somehow or pieces of that And Keep the same semantics, which is which is the core right? Hey, so you mentioned about the 5k nodes number and Basically the edge scenarios are pushing that number quite to the edge and I'm thinking about What what is your approach about how to tackling the Increasement of eventually nodes that running in an higher latency environments, I Think we've never really focused on like the high latency environments to be honest in terms of like increasing the number of nodes like GKE which like there's like Google managed Kubernetes. We already support like 15,000 nodes So it's and it's built on top of Kubernetes. We need to do a bunch of like other things around to make Make that really work and that was like a lot of work, but The building blocks from Kubernetes in open source Kubernetes are there. So It's not that it's impossible to get there if if We didn't see enough use cases that are people in open source community asking for more So we didn't we didn't try to do that in open source because there's like a bunch of other things to do in open source to make that work but But it's certainly possible if we will start hearing those requests But yeah, as I mentioned that we've never really were looking into like edge cases or like Highlight and see or isolated things or things like that. So There is some work happening in that area not in the context of Scalability, but I'm not super familiar with that to be honest Okay, thank you. Okay, and the last question. Oh, there is you had Yeah, what do you think the biggest constraints on scalability are going forward with Kubernetes? Like if you wanted to do 50,000 nodes, what are the biggest challenges you think you'd face? I think there are many different step many different things depending on like where exactly you'd like to go So I can imagine like going to 50,000 nodes With not much effort if you for example run just like simple batch hot per node We're close without using any sophistication in the working storage or anything like that. That shouldn't be that hard Especially if like a low-chair and plaster and so on so it really depends like What are the what are the dimensions that you would like to you would like to To stress more like usually networking stack is it's something that is like most stressing the control plane because there are Most of other things are basically are Basically Okay, they might be taking a step back So we should split the the problems on like control plane components with which there are like very few of them Or I mean very few per cluster not very few components But very few per class like very few instances of a single component per cluster and those that are running on nodes and Those that are running on nodes are usually like contributing like the highest number of like load on the control plane And from those like the networking ones are usually the most The most stressing so this is this is something that we definitely need to We need to come up with something if we really need to go go visibly higher than that In terms of individual components, it's usually boils down to To throughput or things like that like on the individual components which Which is kind of solvable at the per component level, so I would say being able to horizontally scale API server is something that is that is fairly critical and that we may want to invest a little bit into that more the storage layers of the fcd itself is is potential bottlenecks and then like The components themselves will Or can drive like improvements if we really need to go higher, which is in dimension related to that component, which is usually will be throughput or The time to process all all the objects of a given type or something Okay. Thank you very much for coming


I can imagine what can be and be unburdened by what has been, you know? No! What can be unburdened by what has been What can be unburdened by what has been What can be unburdened by what has been No shit! What can be unburdened by what has been What we can see, what we believe can be Unburdened by what has been What can be unburdened by what has been? What can be unburdened by what has been? What are you talking about? What can be unburdened by what has been? Who we can be unburdened by who we have been? What can be unburdened by what has been? Where we can be unburdened by where we have been and unburdened by where we are right now. What can be unburdened by what has been? What can be unburdened by what has been? What can be unburdened by what has been? What could be unburdened by what had been? What can be unburdened by what has been? What can be unburdened by what has been? What can be unburdened by what has been? What can be unburdened by what has been? What can be unburdened by what has been? Unburdened by what has been believing in what can be? can be unburdened by what has been what can be unburdened by what has been what can be unburdened by what has been what can be unburdened by what has been what can be unburdened by what has been what can be unburdened by what has been what could be unburdened by what had been what can be unburdened What can be unburdened by what has been? What can be unburdened by what has been? What should be unburdened by what has been. What can be unburdened by what has been. What can be unburdened by what has been. See what can be unburdened by what has been. What can be unburdened by what has been. What can be unburdened by what has been. Unburdened by what has been and knowing what can be. a sense of vision about what can be unburdened by what has been to see what can be unburdened by what has been what can be unburdened by what has been what can be unburdened by what has been what can be unburdened by what has been what What can be unburdened by what has been? What can be unburdened by what has been? What can be unburdened by what has been? What can be unburdened by what has been? What can be unburdened by what has been? That can be unburdened by what has been. There are those who are unable to see what can be, But there are many more who are able to see what can be unburdened by what has been.