Let's start the actually session now.  My name is Jørgen Mugin, and I will be your host of today's webinar of hardware integration with ToasterFX. The team we have today, you can see it here. In a minute, Martin will take over. But besides Martin here in front, you see Jesper. Jesper is our product manager, heading our technical team. He's available answering questions as we go along. And we have Søren taking care of all the technical stuff, making everything go smoothly, hopefully. Okay, thank you for joining everyone. And please be in mind, put up questions as we go along. We will compact on them in writing, and also some of them checking them verbally. To you, Martin, please. Thank you, Jørgen. Hi, guys. So my name is Martin. I'm a software developer with Tomographyx, and I'll be your guide in today's webinar. So what we'll be doing today is try to get a better understanding of the touch-gift structure generally. And we will develop an application for the STM32F769 Discovery Board, this board. And we'll be using STM32Cube drivers to interact with a few peripherals. And once we've completed all the board setup and verify that all the peripherals are working, we will actually create something that we call an application template in Touch-GFX. It's basically a chunk of code that you can base all your graphical applications on, and that can be distributed and used from within the Touch-GFX designer. And as Jørgen just said, just please ask questions as we go along. After each topic, I'll try to take a short break so we can take some questions. So, yeah, go ahead and do that. So let's see. Our goals today, as we covered just before, won't be involving porting Touch-GFX to new mark controllers and new boards. We won't be covering stuff like general real-time operating system principles and primitives. We'll be using some. And we'll get into those, of course. We won't be getting into CubeMX application generation or project generation. And we won't be getting into specific STIM32 Cube drivers. So what you can actually do is you can go to this link. This is for the F7, the STIM32 F7. You can actually go there, download the Cube package, find a lot of projects and examples that relate to I2C, UART, Quadspy, whatever. And you can use that C code and you can kind of use it along with what we're going to learn today, which is how to kind of interact with peripherals and reflect those changes inside our graphical application, Touch-GFX application. So that's a good idea to do. Okay, so are there any questions at this point? Jan? No? None of this time. Good. Let's carry on. So the agenda today is try to get from A to C. Let's start by talking about relevant hardware. What does it take? What is the minimal hardware setup to kind of run your Touch-GFX applications, static applications? So let's talk about software layers in Touch-GFX and how STIM32 Cube drivers on ST devices kind of affect those layers. And let's go into talking about application architecture when we start developing an application. So we'll be talking about the model view presenter pattern that we use for applications. We'll then get into the core topic for today, how to integrate with hardware. So what we'll be doing today is actually just integrating with a few hardware peripherals on this board, which is going to be just an LED and a button. And this is because then you can actually download the code that we have available today and you can kind of run it on your own board and play around. And we'll finish up by creating the application template and try to distribute that and use it in the designer. And then we'll finish off with a summary and then a Q&A. All right? So let's get into it. So this figure is actually something that you may have seen in a previous webinar. This is something that tells us this is the basic hardware that ChargeGFX needs to run. So we need some RAM for frame buffer, internal, external. We need some flash for our image assets. We need a microcontroller, of course, and we need a display that is typically touch enabled. We have customers that don't use touch displays, but you can still use TouchFX, of course. So what we'll be adding on today is just interacting with some of the peripherals on this board, which is the LED and one of the buttons, as we mentioned briefly. And once we've done this, then we have kind of a chunk of code and board setup or a configuration code that tells us that this board is actually working and then we can at some point in this webinar kind of turn that into an application template that we can distribute to other developers that they can use to develop their graphical applications on top of this particular board or any board. Any questions at this point, Jan? Well, only some general questions we will answer here in writing. Okay, sure. Okay, so you might also have seen this particular slide in a previous webinar. So this is the general software layer architecture for TouchFX. So we have on top the application layer.  Then we have the core, which is where all the rendering, timing and event handling occurs. Then you have the operating system abstraction layer, which is what we require developers to provide if it's operating system we don't support so that we can synchronize framework for access through some OS primitives like semaphores. Then we have the hardware abstraction layer in TouchFX, which is basically the touch controller, interrupt, handling, priority, synchronizing with LCD, handling, DMAs transfers and stuff like that. So generally this HAL layer is where we drive the application forward and protect the frame buffer. And this is something that we won't be covering today, but will probably be a separate webinar because it's quite extensive. So today we'll just be covering this particular board and ST has already provided the board package for us through the link that I provided earlier. And we'll be using that to kind of make an application come to life on this board so we can interact with some of the peripherals. So what parts of these layers are actually affected by cube drivers? So we have the board package, which is kind of all the hardware bring up setting up the quad-spy, setting up the RAM, setting up the LCD, et cetera. And then we have the driver package, which is more TouchGFX minded, which is the MCU that we need to handle synchronization with the LCD. We need to specify how to initialize DMA transfers and we need to use some cube driver code to interact with the touch controller like I to see you something. And so I'll just briefly show you something that if you're familiar with STM32 cube, you can actually see here that this folder here is something that you may recognize from some of the STM32 cube driver packs. This is just basically a copy of that and it contains all the BSP files for this particular discovery board. And here we have a folder which is more MCU specific. This is also something that you'd recognize if you knew the structure of the cube driver packs. So this contains a lot of files related to the F7. So that's just a quick intro there. Okay. So one way to set up your board is to use something like CubeMX, which generates C projects. You can use, I mean, some of the driver packs that they've already provided. And this is something that is required. And as I said, we won't be going into specific drivers today, but we'll be touching on some of them and go through the cube packs and take a look at these examples and projects to get specific examples for I2C, and then you can use it along with what we're going to learn today. So Touch Sapphire is not a display driver, it's basically a piece of software that can render user-defined screens to a frame buffer, relying on hardware events to drive that process.  So every time I mentioned, every time I mention STM32 Cube drivers today, it's going to be basically to communicate with peripherals only. So all the porting stuff is not going to be mentioned today. We are working on improving the integration between STM32 Cube and TouchFX. Before we dive into the next topic, let's see if there are any questions. Well, yeah, let's take a few of them. But they are in a more general range here. Do you have available projects on touchtheeffect.com with communication tasks? We don't specifically, and as I mentioned before, because if you download for ST, the STM32 Cube driver packs, you have a wide range of different projects that touch on UART, ITC, usage, quad-spy, SD RAM setup, everything. So I recommend you check those out. I think you'll find all your answers inside those packs. What I'm going to show you today is how to use some of that C code that you'll find in the Cube driver packs, how you can use that code to kind of integrate or make your applications in TouchFX to come to life. So no, we don't provide specific examples for different peripherals because this is something that's very board specific. And for these ST boards, there are so many different examples available already provided by ST. So let's dive into the application architecture before we start developing. So a brief recap of this slide. This is something that you might have seen on a previous webinar. The right side is something that was covered in the first webinar the last time. So I've kind of tried to gray it out a bit because we won't be focusing on that much today. Instead, we'll be focusing on the gray box, the back-end control system and its integration with the model. So the model is kind of the heart of TouchFX applications. Basically, the model will get ticked by a rate of, you know, we're basically going to be synchronizing with the LCD and so the model is going to get ticked at maybe 60 Hertz. So you could do all your hardware integration here but you might risk blocking the GUI task. So what you can do is if you have something that doesn't take a long time to sample, you can do it in the GUI task in the model tick. Maybe you don't want it to be something to be pulled at 60 Hertz so you could kind of skip some of the ticks and then do it less frequently. But I mean, you're not going to get a very finely granulated control of your polling or your interaction in this way. So what you could do is just add on some more tasks and it doesn't matter if it's not an important task, you could give it a lower priority because the GUI task sleeps a lot while it's waiting for the MA transfers to complete so this might be a fine way to do it. And this is what we're going to be doing today. We're going to be basically creating three tasks, a GUI task, a task for the LED interaction and a task for the button interaction. So this is the application that we'll be making today. On your left you have a basic image. So what we'll be using this for is we're going to be using the button on the discovery board to drive an animation based on this image. And on your right you have a simple toggle button which will enable and disable green LED on the board. And we'll have a webcam that kind of shows you what goes on when we program the board. So I've tried to highlight what we'll be interacting with. So yeah, the user button and one of the LEDs. Okay, so we'll be creating an application on the STM32F769 discovery board. We'll be interacting with the LED and the user button. We'll be doing it two ways. Actually we'll be configuring the button as a basic GPIO input. And we're going to be configuring as an external interrupt connecting it to one of the interrupt lines. And using multiple tasks, free access tasks. And we'll be using cues for the inter-task communication. And we'll try to show the relevant code changes for each of these. And I'll try to take it slow because the update frequency of the webinar might not be fast enough for everybody. So I'll try to take it slow so that we won't miss any code. Okay, so we'll start off by creating a simulator version. And the peripherals we'll be using here is we'll be using the keyboard as the input peripheral, as the button. We'll use the console window as an output peripheral just to see that we can turn on and off an LED. For the target version, we'll be touching on this just to show you that we'll be using some of the STM32Q files here. We'll be using the GPIO C file, which is MCU specific. And it relates to interrupt handles, among other things. And then the discovery.c file, which is board specific and allows us to set up and reject with the LED and the user button. And then I will be connecting the user button. The user button is connected to one of the external interrupt lines, line zero, and we'll be using defining an interrupt hand of this purpose. So what we'll be doing is through the designer, you can run the simulator in a simulated environment and you can also run your application on target. And what we'll be doing actually is we'll be using STLink, this utility here. So based so we have an external flash load configured here and we'll connect to our targets and we can program this board using this. Or we can use the make files that we generate using the designer which already uses this tool in a command line version. Briefly on the designer. We had some questions on the first webinar that we thought it would be a good idea to integrate into this one. So the designer actually just generates code based on the contents of your project and it only touches the generated folder. So you work in screen definition classes that are derived from the generated ones, which means that the designer is not going to be overriding any of your work. You can add any additional target specific code files to your compiler projects and it won't get overwritten. So we'll just be using the designer to generate some code for us and then we'll be modifying some of the inherited versions of those classes. So let's, before we dive into that, see if there are any questions, John. Yeah, we have one, well, I think you had to open the editor. What is the name of the editor Martin is using? It says. Oh, this one? Yeah. Yeah, that's sublime text. We actually got the same question in the last webinar. So some of us use this editor. It's kind of like text made if you use Max. It's a pretty fast editor. It has a good fuzzy search. If I want to find something like the model, I'll just type something and it'll give me some suggestions. So anything, I can type anything, it'll give me some suggestions. It's pretty easy to navigate. Yeah, so. Well, actually, we got an input here that it's really hard for them to actually to see the font is too small. Maybe this is, I don't know if you can make it bigger. How about that? Yeah, perfect. Can we get some input on this size? Yeah, please, please come back on if you're able to actually read it now. Yeah, okay. Thank you. Okay, so before we dive into. Yeah, so any, any other questions, John? No. Okay. Okay, so let's let's open the design and start. So this is the application that we saw previously on a slide. So this particular image here is going to be, we'll be using that image to kind of drive an animation here. So you can see here it's a basic image. We also, the design also supports something called an animated image. But basically we want to control this image and it's the way it looks by controlling the button on the board. And this particular button is what we'll be using to control the LED. It's a toggle button. So it's either on or off. And we have one single interaction defined in this design that is, when this button is clicked, we can call a new virtual function that will define the name of here. And that is something that we can then override inside our derived classes and then add some custom functionality. Okay, so let's have a look. So what I'm going to open now is the base class for the screen one. So I'm not sure if you all saw. One comment, Martin, switch screen is too small to see. It's a comment. Let me just open this. So it's full screen. How's that? Okay. So screen one base is something that is the HP and the CPP file are generated by the design, as you can see up here. So the path is generated, GUI generated. So this is the files that we're looking at now. So we check out what the design has generated for us. It has generated a button handler for the toggle button and it has created a virtual method that we asked it to, the updated LED state. So what it says here is that override and implement this function in your concrete view. Okay. And if we check the code for this, so we're still inside the generated GUI generated folder. Here the callback handler for the button just defined like this. This is also generated by the sign. It checks, is this the button that we pressed then call this virtual function, right? So now we can kind of get to work. So we're actually done with the designer now. We've kind of created our layout and we've told the button that it should actually be calling a virtual method when it's pressed. So let's just minimize this for now. So if we check the screen one view, this is the inherited version of the base class that was generated by the designer. So you can see this is located inside GUI, include and GUI source. And the other generated screens were located inside, generated, GUI generated. So if we check out this file here, so basically what we've done here is override the virtual method, update LED state. So for now we're just discussing the LED flow throughout the application. And if we check out the view, which is located inside the GUI source folder, basically what we're going to be doing when this method is called is we're going to be talking to our presenter and telling it the state of the button, the current state of the button which might be on or off. And let me just go back to one of the slides here. So the flow is basically the presenter updates the view. The presenter can update the model and receive state changes from the model. The view can talk to the presenter and receive events from the presenter. And we'll be using the model to kind of make all this happen. So let's have a look at the model for a second. So what happens here? So basically what we talked about before was that the tick method of the model was kind of the heart of the application. It gets ticked based on the synchronization of the LCD. And so here we're going to be, instead of doing our sampling here, we're going to be talking to some free artist message queues. And I'll be getting into that as well. But if we take a look at the screen one presenter, so the view just called this particular method with the state of the button. The presenter as we just saw on the slide, we are architecture slide, is going to call the model with the state. So if we check out this method on the model which is located inside the GUI source model folder, for now, since we're just using the console as a peripheral, we'll just be printing out the state, right? And we'll be saving the state and we'll be updating the LED state, but this is only if this is not a simulator. This is for the target version. So now we're just kind of verifying that our behavior in the simulator is correct. So what are we going to use for simulating the button? We're going to be using something, a method called handle key event, which we can override inside what we call the front end application. This is located inside the common folder, right? So we'll just be calling a model if the key is one, calling model a method on the model called button pressed. And this is the same, we'll see that this is the same method that will be called, let's go back to the model, the same method that will be called if we receive something from the button task. So that's just a teaser. Okay, so I think we're ready to try this application. So we've just verified that the flow of the button from the view into the model and we verified what happens from the peripheral, the front end application, the key event from the keyboard and it's going to drive this application. It's going to drive the animation. And if we just take a quick look at that, what it's going to be doing is going to be calling a method called advanced animation. It's going to change the bitmap ID of this image and it's just going to keep cycling that until it hits the maximum ID and it's going to reverse the direction and then it's going to reverse again when it hits the base ID. So let's just try to build this application and run it. So this is actually something that you can achieve from the designer by just clicking run simulator, but I like to use the environment here because then we kind of see what's going on. So the environment is something that you probably have on your desktop. It looks like this. So let's see it. So here we go. So this is our peripheral, which is the LED for now. So when I press 1, this is going to simulate a hardware pressed button, right? So it's going to advance an animation. We can keep it pressed. So it's going to continuously update like this. We can single stab it. We can click the button and it's going to update the LED state, right? Okay. So now that we've kind of taken care of that, let's go into talking about how to actually integrate with our hardware. This is the most important, most interesting thing today, I think. So basically we'll be defining two tasks. Let's have a look at how those are defined. Now we'll just be going to the target main.cvp. We have three tasks. We have the GUI task, which you will always do. We have two additional tasks called the LCD task and the button task. And something that I mentioned that we wouldn't be covering today is the hardware initialization and the touch defection initialization. And so this hardware initialization is basically where all the STM32 cube driver code is working and smatching, setting up the peripheral, setting up the quad spy, the RAM, the LCD, et cetera. And this is where all the touch defection magic happens, which is what we call the touch defection export. So we're going to be defining, this defines which bit depth to use, which DMA class to use, how those DMA transfers are going to be happening. And then we're just going to start the schedule. So if we go back to the model, what we can see here is that the only input to the application is the button press. So the LED interaction is happening from the view. So we're receiving a press on the screen and then we're going to be wanting to activate one of the LEDs. And for the button, we're going to be continuously checking if a particular queue has a message for us and that means the button has been pressed. And for the LED state, when we click the toggle button on the view, what happens is that this method is going to be called and then we're going to send a message to a different message queue, which is in the LED task. So let's have a look at the LED task. So here we're going to create a message queue. This is actually a STM32Cube call. So we're going to initialize one of the LEDs. We're going to continuously, every 200 milliseconds, we're going to be checking this message queue if the GUI task has sent us a message and we're going to be turning it on and off depending on the value. These on and off methods are also STM32Cube calls. So for the button task, and these are just located inside the target folder. You can place these anywhere you want. These are not faster. They will be overwritten by the designer as long as they're a part of your make file or your project. So here we're going to be initializing the button in a GPI mode and we're going to be sampling the state of that button every 50 milliseconds. So this call and this call are both STM32Cube driver calls. We're going to be creating a button message queue that we're going to be using to communicate from this task if we experienced a button press. And this is something that, this is the message queue that the GUI task is evaluating in its tick method continuously. Okay, so I think we're ready to actually try this application, right? So instead of calling make simulator, we're going to be calling the make target you see make file. And I've already programmed the external flash because there's a lot of images involved in this application. So instead we can just flash the internal flash with the code changes. So, and do we have, yeah. Okay, so it's programming the board. Okay, so you should be seeing now. So basically what happens here is that when we press this button, the green LED is actually turning on. It's turning off. And this is because of the flow that we talked about from the view to the presenter to the model from the model through a message queue a free access message queue to a task that continually pulls this message queue for information. For the button, we can single step as we did with the keyboard or we can continuously advance the animation. So what happens here is that the button task had a free access queue that used to communicate with the GUI task and the GUI task continuously checked if there are any values, any information inside this message queue and then calls the something we need to see here from the model again. Button pressed, we call the model listener, a method on the model listener and the model listener is something that all presenters is an interface that all presenters implement. And if we follow that flow, what we can see here is that we override this method because we're interested in the signal and if we go to the code we'll actually just be calling the view and telling it to advance the animation and we saw the code for that already. So this is just to show you, so now we've talked about the flow all the way from a peripheral through message queue in a task to another task from that task to the active presenter and then to the view and the other way around from the view to the presenter to the model through a message queue to different tasks that evaluates that and then talks to peripheral. Okay? So something else I've prepared here is to have a... So this was a GPIO configuration of the button. So what we can do actually here is make it interrupt based instead. And this kind of changes a little bit how the button task looks. So now we're not doing anything inside the task. We can use it for something else so we can remove it and then define the message queue somewhere else and then we have this because the button is connected to the external line 0. We'll define this interrupt handler which is defined inside the interrupt vector table as well. We'll be checking if this message queue already has a message waiting that hasn't been taken by the model yet and then we'll be sending a message from this interrupt handler and just notice that we'll be sending it using a different method that is called from ISR. So this version of the XQ send is basically just a version that does not have a code to block your task or to halt your task. So you can actually also call this from a task but you won't get the expected behavior maybe. In the end we'll be calling the... This is actually a call to STM32Cube drivers as well. So what happens in this method, I won't be showing that, is that it's going to clear the interrupt so that it won't be firing all the time. So again this is something that is STM32Cube specific that we can use based on this driver package. So let's just see if the behavior has changed now. We'll be compiling it, programming the board again. So the behavior has changed now because we'll only be getting calls to this interrupt handler every time we press the button. So the LED is still working and the button is now only single stepping the animation because we're only going to be receiving one interrupt every time it's pressed. So those are just two different ways of using STM32Cube driver code to perform this peripheral interaction. So just to summarize, you could use your GUI task model tick if your sample time was small like maybe a millisecond and we could use tasks to have that more finely granulated and since the GUI task is sleeping a lot while it's waiting for the AMA transfers to the frame buffer to complete, we can actually just... So it'll sleep a lot and our peripheral task will get scheduled in, so that's fine. So let's turn back to slideshow. See if there are any questions. Yeah, thank you, Martin. Yeah, actually we have a lot of questions and this is great and please keep them coming. One about the model view presenter. Why using this? And what are the advantages of using the model view presenter? Well, it's a nice abstraction. Well, it's a good abstraction pattern so basically the model view presenter pattern as compared to the MBC pattern is something where the view is actually active and actually has an active role in this application and the presenter is the middle man so it talks to both the model and the presenter and since we just talked about hardware integration and peripheral integration, this is a good way to kind of have a asynchronous access from the model to an active presenter so the model can just say are there any presenters that are interested in this particular message and if an active presenter isn't it won't have that method implemented. So for us and for this general flow of how we do these applications, this is a nice architecture. Yeah, thank you and we can add that it's a really recognized way of doing UI applications. We have also some general, some is pointing at supported IDEs and what is actually available in TouchGFX evaluation. Can you comment this? Yeah, so the touch... And one is specific, asking for Kyle, microvision 5 if this is supported. Sure, so the TouchGFX evaluation version has no functional limitations. The only limitation as you can read in the license agreement when you install the designer is actually that you cannot use it to create projects or products, so there are no limitations except that you won't have the ability to create products and you will have a watermark that appears randomly. What we're doing actually when we use the designer is we are creating Kyle and IR projects and Visual Studio projects and GCMAKE files for a particular application. With Kyle 5 support as well. So what you're saying is that the Kyle microvision 5 IR is fully supported. Projects are coming prepared for these IDs. Exactly, but for some supported boards the Kyle version is still Kyle 4. We haven't gone back and upgraded all the different projects every time a new ID version comes out. And we have an additional comment to this. What about MGU Expressio for IMX? Yeah, so I'm not quite sure about the exact roadmap for this, but this is something that we are looking at and have tested inside the lab. And I can add actually for some boards it is supported from MGU Expressio. Projects are created for some of the NXP boards. Okay, so let's continue. So now that we've kind of verified that the hardware is working, the peripherals are working, we're kind of happy with this board bring up. Let's pretend we've done a complete board of such effects and we've written some drivers and made some stuff work. We kind of want to distribute this to whoever else is wanting to develop for this board. So we can actually using one of the tools that we have in the designer kind of pack all this up and then we can distribute the file we call an application template and people can use this from inside their own designers. So let's just have a quick look at that. So there is actually, let me show this browser here, there is actually an article for creating a custom application template. And what it tells us is that, you know, what we should do is now that we have all this code, all these drivers, et cetera, in here, what we should do is kind of clean it up so it has a minimal size. And then we can call touched effects pack to generate an application template. So let's just try to do that and show you how to get that into the designer. So I'll just, so here is the command. So it's located inside the designer folder inside your touched effects installation and then tgfx.exe pack. We'll start with just the D argument which is kind of what generates the pack for us, prepares some adjacent file for us that we can use to describe this pack to everyone else. And before we do that, we're just gonna close down the designer because it's locking some of the files that we need. Let's just try to run it. So I haven't really cleaned anything, so it's gonna be, it might be a lot larger than it should be. So now it's found the touched effects file, which is the designer file. So I'm just gonna start processing that and it's gonna pack up all the files. And while it's doing that, I can just show you what I've already done here. So what it's already done is created a adjacent file for me and I've called this the webinar template. The board name is obviously a 769 discovery. It's a touched effects application template and I provide a custom image that will be displayed inside the designer. So now it's created the zip file for us. So the article now tells us to do all this stuff, describe the application, provide the proper type, the touched effects application template and then use the RC argument to create the final application template, which is the TPA file that will be distributing. So let's have a look at that. So I've already done this. So while it's doing its work, okay, so it finished before me. I'll just be taking this file and according to the article, we're gonna be installing it inside the packages folder of the designer. So let's go to touched effects 493, designer app packages, let's put this in here. And then when we update our designer, start it again. We should have access to this application template. So what basically happened is that it stripped all the GUI that we used for testing and now when we create a new application based on this webinar template, we're just gonna start with a blank UI because it's a new project. What happens now is that it's gonna create a new application called MyApplicationFor and it's gonna have all this porting code and all this STM32Cube driver code that we generated using Cubamex or took from a driver pack or something. And now it's kind of ready for people to use and create their own applications. Let's just make it finish. So here we have, we're gonna be staring at a blank canvas and we can just start creating our own application now. So that's it basically. So now we've gone all the way from talking about some of the hardware requirements. We've talked about the different layers of TouchGFX. We've talked about the cube drivers and how they fit into the various layers. We've developed a few concrete applications that test this hardware and these drivers and we've distributed that application template and used it to create a new application. So this is kind of all the way from A to C without discussing the porting specifics. This is something that we're gonna be talking about in a different webinar as well as how to protect the frame buffer using real-time operating system primitives, which is the operating system abstraction layer that we saw in a previous slide. So this is just pretending that we already have the port and we already have the drivers and we communicate with some of the peripherals and showed you how to kind of make your application come to life both from the GUI to the peripherals and from the peripherals to the GUI. So are there any questions at this point? This is the end of my talk and I just wanna say thank you for listening. I hope you enjoyed it and got something out of it. Yeah, we have some questions. Most of them are correct. We have one asking about the IDEs, the plans for actually supporting Atolic True Studio and I can actually answer this one right at the moment. We are not supporting Atolic True Studio though a lot of customers are using it. We have a guide and we actually have some forum guidelines also from customers supporting you in actually doing trust effects projects in True Studio of Atolic. We are working close with ST, so both with integration with ST Cube but also ST IDEs as Atolic True Studio. So this is definitely something that will be more integrated and supported looking forward. And I just wanna add that this is a question that we get a lot. What about Atolic integration? What about Eclipse? Anything Eclipse based, STM32 workbench as well. And this is something that we will be creating an article for because the process is actually fairly simple because if you pretend that you generated an Atolic project from CubeMX for instance, basically it generates C project for you. So you'll just rename main.c to main.cpp, call a few methods and basically then you'll have trust effects integrated. So the process is really simple and we'll be creating an article that shows you how to do that. Yes, yes, Chromart is actually... Please repeat my question. I didn't... Oh, so yeah, using the Chromart is actually the very core of how we perform well on ST devices. So that is extremely central. Okay, good. Before we close down, I will actually ask you to still keep on putting in questions. I would like to launch a poll here for actually looking into a new topics for upcoming webinars. So please put in your vote here and we will take this into account. We are in the process of planning webinars for the rest of the year. We are just counting technical webinars like this one, also counting more actual graphical design, how to do graphical designs, which is also an important part of a good UI solution. Yeah, please make them coming here and I will close it in a few seconds. We can see the results here. Yeah, and you are saying here that general porting parts is of your high interest. And we will definitely do this. I think also there were some questions about configuring of the DMA and so on, but this is not a topic of this webinar, but we will do this in the future. But also more advanced application development using the thirsty effects designer and also doing more sophisticated coding by hand in C++. Great. Regarding ARTSAS, let me ask you about your usage of your OS. Please put in your vote here. We are using free ARTSAS in our examples and it comes with thirsty effects. But thirsty effects is independent on the ARTSAS, so you can choose anyone. And there is a guide helping you in updating the OS wrapper and porting to another ARTSAS. Just give it a few more seconds here. I will share it. Oh, it's quite clear here. Free ARTSAS. The others, please put in in writing what you are using here. And we will also have this in consideration doing future seminars on ARTSAS. Let's go back to the slides. Martin, just please. We will be online some minutes after the webinar here answering questions. And I'm just checking if some is coming in here. And please, when you leave, please go through the survey and give us input from this webinar. This will be appreciated very much. Several of you are asking how to actually get the video here, how that will be made available. CERN will send you tomorrow a link for the recordings. So you can download and share as you like. And we will also keep them in our website so you can always go back and get it from our website. Next slide. I just have one comment here. One is saying, I don't use an ARTSAS. Fine, an ARTSAS is not required. You can run on the bare metal. And yes, if this is what you want, no problem, trust your fix is not needing an ARTSAS. You have a comment for this? No, that's correct. It's limited in where you can do all your calculations, like in the porch areas. But yes, you can run without an ARTSAS, just fine. Okay, thank you everyone for attending today's webinar. We will be back with a list of upcoming webinars. And I hope you have enjoyed and learned some of the issues you were looking for. Please put in your evaluation on the survey and have a great day. Thank you for now. Bye.


OK, so I've been given the signal to start. How do you like our new logo? Some people say it looks like Google, but really, we started before Google. It's not fair. Anyway, my name is Jesse Martin. I'm a cloud architect at eBay. And you may have seen recently some press release around what we are doing with NICERA. I don't know if it was because NICERA was just acquired by VMware. There was a big price associated with it, or if it was because everybody was excited about what we are doing. I'd like to think that it's the second one. So I'm going to talk a bit about what we are doing at eBay. And I'll go from a quite high level to pretty detailed, because we want to make sure that you understand behind SDN the hype, what we are really doing, and how we are using SDN to run our developer cloud. So you may wonder, what's the problem with my title? I'm not showing, so it's going to be interesting. So eBay is not really a public cloud provider. It's not a cloud provider. But what we have is many different businesses. So you know eBay, we have PayPal, and we have a bunch of others. So what it means is that even if we are an internal provider for the eBay Inc organization, we still have a lot of different businesses that may be potential users of our infrastructure. What it means also is that those users, they may have different environments. For example, at eBay, we have a production environment. We have a production secure environment where we put all the information that identifies users. We have a QA environment. We have a developer environment. And same thing for PayPal. They have production, PCI compliant environment, QA environment, and developer. And it's the same thing for all of them. So even though we don't have a typical public cloud multitenant infrastructure, we still have a lot of different environments that we have to support. So traditionally, those environments, they were implemented as physically isolated environments. And this creates a lot of problems. So we'll talk a bit about that. So now we tried to convert this infrastructure, and we looked at the principles that we wanted to apply on that infrastructure to build it. So the first one was that we were supposed to be able to deploy any application anywhere. So what it means is that if you have some resource available in one side of the data center, you should be able to use it for front end, even if before, only QA was using this side of the data center. The second one is soft cabling. What it means also is that if you want to create a new network, you should not have to go in the data center and wire different machines to different networks. Shared, standardized infrastructure. So that's also very important, because the fragmentation I was talking before about is also caused by a lot of different infrastructure requirements. So we used to have more than 100 different server types at eBay. And we are starting to reduce that number to a few standard servers that users can select from. And this improves a lot our efficiency and ability to automate. The next one is to virtualize everything. A virtualization doesn't only mean running an hypervisor on top of a compute server. It means that everything that we do should be abstracted from the application. So for example, it could mean network virtualization, storage virtualization, and compute virtualization. The main reason is that we don't want the application to depend on some specific characteristic of the hardware, because if we want to change some hardware model or characteristic, the application should not be impacted. And the last one, the most important is to automate everything. So based on those principles plus the problem that we had before, what we had to do is convert all those physical environments into something that can be automated and can be deployed more easily. So we try to first convert all those physical environments in what we call class of service. So a class of service, if you want, is an extension of an SLA or quality of service. It captures everything that you would implicitly implement in your physical environment. So if you have a QA environment, you are going to have firewall rules. You are going to have access permission, a definition. You are going to have support specific contracts, and so on. So we try to capture that into a logical entity that we call class of service. And then what we do when someone creates a project or a logical environment, we ask them, is it a production environment? Is it a developer environment? Is it a QA environment? Is it an external environment that is going to be completely externally facing? And based on that, we are controlling how the infrastructure is configured. So what it means is that in a typical cloud provider, you have provider-specific rules on what tenants can do. Here, we don't have only one set of rules, which applies to all tenants. Depending on the type of project that the tenant is going to deploy, we reconfigure the provider-specific constraints and capabilities to fit that specific class of service. And this allows us, for example, to run together on the same infrastructure, QA, production, developer, and external class of service. And we reconfigure around that logical environment the provider infrastructure so that we can enforce all those restrictions and obligations. So now the other aspect of what we are building is we wanted to have a shared infrastructure. So I'm going to go in the details of our network. The main design goal for our network was scale. And we wanted it to be as simple as possible so that the network engineering team would not have to build environment-specific networks. So we had this design that's based on the spine and lift, which is pretty much an industry standard for scalable network. It's a layer three type of network. So there's routing happening at every level. So the drawing here is a drawing of a switch, a label of an icon of a switch, but it's really a router switch. The size of that infrastructure depends on the number of ports that you have in your spine. So you could have the same switch in your spine that you have in your lifts, which means that you would have 48 ports here. And four times 48 would be the maximum number of, 48 times 48 would be the maximum number of servers that you can have in your environment, in that topology, right? So at eBay, we call that topology a bubble. Some people might call it a pod or I don't know what's the official term. Anyway, the key parameter here is that we want to have line rate or a consistent oversubscription from any node, any two node in that infrastructure. So it's consistent B-section bandwidth and latency across all the nodes in that infrastructure. In order to achieve that, since there's multi-pass to any node in the infrastructure, we use OSPF and ECMP for finding the best pass between the two nodes. So now if you look at this infrastructure, you realize, but how do you do isolation? Because you have a large infrastructure which has between 5,000 nodes to 10,000 nodes and you cannot really interpose easily firewalls or control points. So if you look at the options, if you want to do it at layer two, one of the options here is to basically build smaller physical infrastructure. It's not really efficient because what's happening is that first, you have to build that infrastructure physically for any new project that you want to start on a new class of service. It creates fragmentation because the size of that network is not really flexible. The isolation is quite coarse-grained because it means that every node within the same network here has the same reachability to any other. So you cannot isolate this node from this node, but you can isolate this one from this one. So the isolation is still coarse-grained. The best thing is that there's really physical isolation. You can guarantee that a tenant here cannot see this tenant here. And it's foolproof because there's really no complex technology involved. Maybe the more complex part is the firewall in between the two networks and that is pretty standard design. The other option is VLAN-based. So what you do is you still have the same infrastructure, but instead of being flat L3, you have VLANs and you assign machines or VMs to a specific VLAN and you can have a firewall between the two VLANs. It's pretty complex because you have to do VLAN assignment for every project or class of service, which means that you are limited in how many network or how many projects you can create on top of that infrastructure. There's one limit which is 4096 networks or VLANs, but there are some techniques to increase that number, but it's not the main issue with that infrastructure. The main issue is that it creates a large layer two full domain. If you have a problem in one of those layer two VLANs, it may impact all your network because of the way STP Spending Tree Protocols operates. It takes some time to fix issues in STP and you might end up with some outage while the STP protocol recalculates your networks if there's any kind of miscabling happening. The good thing is that it provides layer two isolation so you could have layer two adjacencies between those nodes. They could use the same IP address space, the same network, and it's somewhat soft cabling because you don't go in the data center and pull wires, but you have to reconfigure a network switches to add, for example, a new tag or to allow a tranking. So that's layer two. Now the other option is layer three. So you go back to my first scaled out network where everybody can talk to everybody and you put some layer three filter either, for example, in the hypervisor using security groups, or if you are using hypervisor, you could have, for example, something like VShield that is redirecting the traffic of all the VM to a local firewall and this local firewall is going to provide this isolation. What we found is that there's, the good thing is that it allows you to have this scalable design that I mentioned before, the spine and lift layer three. It's good for user policies because it's a pretty lightweight to add, for example, security groups and rules associated with those security groups. But the problem is that when you are trying to combine those security groups with provider security, it becomes very complex because if you look at the Amazon security groups, by default, you can send traffic to everybody. But what if you have a provider rule that says, no, you cannot send traffic to this, you cannot reach this part of my network or there's some service that you cannot reach. It starts to have the combination of all those rules starts making it very complex. So I think it's good for tenant specific policies, which are a specialization or if you want a restriction on top of the provider policies, but I don't think it's very good when you try to combine the two together. The other problem is the management of rules because those rules have to live on every server. And if you modify the membership of a destination of your rules, you have to update all the servers. For example, if you say all my VM can talk to this group of machine, if you add a machine in the target group, you would have to update the rules in every server. Even if the firewall technology that you are using is doing that for you, at the end of the day, they have to modify the rules in every servers that have this rule specified. And if you are using L3, you may have those machines in complete different subnets. And it's very difficult to do root summarization or aggregation when you want to rule aggregation or summarization when you want to define those policies. So you might end up with non-efficient policies. So the solution that we found was to use virtual layer two networks that are provided by VMware and NISERA. So it's kind of like VLANs. You can specify that a VM or a server is part of a network, a virtual network, and you can put a firewall between those networks. So you can prevent them from talking to each other if you want, or you can prevent the routing between those two networks if you want. That SP space can be completely separate from the SP space that you have in that layer, which is very useful because when you have 48 server here and you put VMs on top of those servers, the number of IP that you have to provide for each rack is huge. So for example, you have a slash 24 for this switch, but then if you have 10 VMs per rack, per machine time for 48, it's already 500 IPs, plus you have to have some for the management and so on. So at the end of the day, you end up with wasting a lot of IPs there. So the nice thing is that you still have layer two isolation. That guy cannot see this one unless there's a route between the two or there's a firewall that allows that. It's compatible with the large scale network design that I mentioned before. Can be fully automated. Everything is configured through APIs. You can still enter post network to have provider specific policies. It can complement layer three isolation because I can still run security rules on my own VM if I want to or in the hypervisor or some other place in the network. It's still compatible with this type of isolation. And you can have a large number of networks not limited by some tags like the VLAN tags. The negative point is that you have some tunnel overhead to perform that layer two isolation. The traffic is going to be tunneled on the provider network. And the size of those networks is limited because for every layer two network that you are constructing, you have to have tunnels between any two members of that network, which means that it's growing very fast, but it's not different than the type of limit that you have, for example, on the physical switch where you have 48 ports and that's it. So it's giving you, there's still some limit but it's still something that we can manage. So what is SDN? Really to very simplify at the maximum and I hope no one is going to blame me for that. If you look at the architecture for a switch or router, you have some logic that is defining the behavior of the switch engine. So that logic could learn about the network from some protocols. It could be like a Mac learning logic that is going to add some entries in some Mac table in the routing engine and that's the typical design of a physical switch. Now with SDN, what you do is that you still have this routing or switch engine. It could be a virtual routing or switch engine that runs in an hypervisor, for example, but that switch is kind of a dump. It's a slave to some logic that exists either in an agent on that machine like the Midokura solution or it lives in some centralized controller like what NICERA is doing. And that centralized controller either through protocols can also learn about the network but most importantly it can learn from APIs. So what it means is that instead of trying to discover that a new machine was created on an hypervisor by listening to Mac address, since you know that you created that machine on that hypervisor because you are the one that actually did the instantiation of that VM, you can pre-configure the switch to already know about that VM because you know the Mac address, you know on which hypervisor it was deployed so you might as well put the entry in the Mac address ahead of time. Like that you don't have to go through the discovery phase which could be based on ARP for example and if you want to move that VM from one hypervisor to the other one since you know that you are moving the VM you can reconfigure the network at the same time you are moving the VM which avoids all the problem of IP migration and rediscovering where this IP went and find out how to reach that IP and most network is going to break the connectivity anyway because you are changing subnet and things like that. So that's like two minutes what is SDN at least as far as I understand it. I'm not going to go into details of what's happened in there or in there because it's too complex. So now the other aspect of SDN is still my opinion SDN experts might disagree but there's kind of at the bottom what we are using at eBay right now which is just like playing with overlay networks. So what it means is that we are not really reconfiguring complex routing or complex behavior of the switches and we are using virtual switches in hypervisors. The type of protocol that we are missing with is ARP and L2 protocol. In the future we might do that with L3 but it's still going to be pretty basic. Then you can do more advanced things if you have physical servers that are also implementing SDN and now you have physical servers that can be part of a virtual switch by membership of ports and other criteria. And at the top of the totem is maybe what university are doing right now with SDN or OpenFlow which is completely implementing new traffic engineering behaviors by reconfiguring network switches so that instead of using for example OSP, FECMP and having kind of a basic understanding of the network through protocols you can also configure the behavior of your network based on how you understand it. So for example if you have multiple paths to a machine instead of saying all the paths are equal and that's a static configuration you may want to say okay this link is saturated so I'm going now to switch more of the traffic on that other link or there's some very important traffic on that link so even if it's more costly to go to this other link I'm going to do it because there's some important traffic on that link. So you can play with more like the behavior of the switch without relying on complex protocols which might not know at all what your network is trying to do because they have kind of a myopic view of the computing environment they only see their peers and what their peers are telling them. So that's the simplified view of SDN and as I said for now we are playing in that level so not yet Ninja or Wizard of SDN. So the first implementation that we did is because we wanted to learn also at the same time it's pretty new technology we started a year ago just when Nisira went public with their offerings. So we wanted to try out on a use case that was not like production sensitive that happens that people that are using them developers they are pretty nasty and when it doesn't work they tell us so even though it's not production you don't want it to be down so the developer cloud what it is so it's a logical environment similar to what I described before with a class of service that defines what they can do and we give them a cell service API that they can use to get VMs so we are not using horizon yet we have our own layer because we wanted to strip it down to the maximum so that they don't break anything but the idea is that it's an environment that where every developer should be able to put their application and collaborate with their friends because before what happened is that they would run an application on their desktop or their laptop but at the end of the day they close their laptop their application is not available anymore or they put it on their desktop and every first day their desktop is rebooting so they have big stickers please do not reboot so that cloud is giving them a place where they can run their application and we had an experimentation event that's called Skunkworks where all developers at eBay can showcase a project that they developed in their free time and we use this environment to give them infrastructure to showcase their projects to VP and the winner at the privilege to have their application on the site live so it's implemented as a set of layer two networks and we'll go into details soon and we are grouping those networks layer two networks in one big layer three networks and we have a perimeter firewall that is controlling access to that layer three network and what this layer three network can access outside we are not exposing yet private networks so developers are sharing the same network and this is something that we will do in the future is allow developers to have their own private network and play with more complex infrastructures topologies if they want to and it's isolated from our production infrastructure so the important thing and we have some representative of our operations in the room what is pretty scary is that we are giving developer access to our production site except that they are not really on the production site because they are isolated through layer two so we are using our shared infrastructure that we are leveraging for production which is high scale and on top of it we developed and deployed this developer cloud but none of the traffic that the developers can generate is going through that production network because it's routed outside it's transmitted outside through the tunnels to the gateway that bring that traffic outside of the production network there's some traffic that can reach the production network but it goes through a firewall first so it's a very interesting proposition for us because now if we want to reclaim the 40 servers that those guys use or 100 or 200 servers that those guys use we can kick them out and use it for production we don't have to change anything we just have to re-image the server and it's done if we want to use some spare server to give them more capacity because they have a big project they want to test some algorithm on 150 servers we can also do that we just take temporarily some production servers we attach them to that network and they can experiment with that infrastructure so very important to enable a scale out test and we already have some projects that requested like 16 VM to do some messaging tests they could not do that on their desktop that's definitely not an option and we cannot give to anyone their own environment to do those kind of tests so now if we go in the details so there's a lot of details here you should be able to almost do the same thing that we did if you take that topology so I mentioned that we created virtual networks which are pre-created so for example we created 10 networks 10 virtual networks each, so that's a Nova network gateway with a virtual switch, OVS kernel module and every time you create a network using NovaManage there's a gateway that is created on that network upstream we have one interface that goes to the firewall for access to our corporate internet or QA network and one interface that goes to the blue network which is where all the provider network is where all the production network is like an infrastructure network so when you create a VM it logically has an interface on the green network it's tunneled through the virtual switch back to that box and there's a set of policy-based rules that are directing the traffic coming on those gateways to the orange link so that it goes through the firewall directly and we allow them to talk to each other but we don't allow traffic to be routed outside of that dotted line here so what we run on that box is Nova network metadata API so that CloudInit could work here on every hypervisor we have the standard KVM and Nova compute plus the OVS switch the root here is just basically the their gateway interface we have in terms of infrastructure we have the scheduler, the APIs and Quantum Quantum talks to the NICERA controllers which is on the same network and the service nodes so it's pretty simple if you want the only trick is that because we are using Nova network and we are not using the HA a way of deploying Nova network we had to figure out how to make the gateway HA which means that when for example this box dies the standby gateway can take over the traffic routing for the networks so what happens is that we have a pair of switches and a pair of firewalls each connected to those two standby standby and active gateway and the Nova network when it restarts recreates all the gateways and routes that are required for the traffic to go through the standby gateway and we fail over this IP here that is the IP that the switch that the firewall is using to send traffic back to the dev cloud so it may happen that we lose some traffic the failover is not instantaneous so it's not the best solution but so far we did not have any outage and we did not have to try our HE logic which is good in terms of tricks I can talk a bit more about the flow and you will see how this happens so we have our cloud portal that is used by the developers and here you request an instance automatically we tag this request with the class of service the type of OS that you want and the size and we have an orchestrator that is going to frontend the request the main reason we have this orchestrator is that we need to configure DNS and today in Nova there is no easy way to automatically configure DNS and we are evolving this architecture to be completely based on OpenStack removing the green component here but this requires some acts and hooks that we have to put into Nova so when you have your instance at some point you create the VM on the compute you have a phase where you have to get the IP and create the port so that goes through quantum quantum talks to the NICERA controller creates the port the port is attached to the network the switch is created by the administrator when you create the network so you have to map the switch to the network which is done through some tags in the NICERA controller at the same time when you create a network what happens is that you have to create the gateway and the way this works is OVS implements a bridge emulation Linux bridge emulation so by using just the same Nova Nova network processes to create the gateways the bridge is created not a bridge sorry a gateway interface is created also talking to NICERA attaching this gateway to the same network logical switch so that's the basic flow this can be simplified there's two elements that I want to point out one is because we pre-created the network and we have a maximum capacity for each network of 256 IPs we need to assign ourselves the network for each request we cannot let the tenant choose their network so what we do is we look up the Nova database we look at how many ports are already assigned or how many IPs are already assigned in that network and we select the next network that is available and we send that network information as an extension to the boot instance and so we worked someone in the room, Subu implemented an extension to the Nova scheduler in order to do that so we can remove that step from our internal orchestrator and we also have the requirement to create DNS entry forward and reverse for the created VMs so today we do that through some glue that is listening to IMQP to RabbitMQ and there was a session previously talking about the future of DNS in OpenStack and eventually this DNS management will be a component provided by OpenStack so that's the flow now some people say you're crazy to use OpenStack it's not stable so for us that's our availability here since we opened the two deep I think I am to blame for the two deeps because I did some operations on our infrastructure without using the right interface and I caused some issues but otherwise it's really stable for us and if you look at the interesting graph here is the latency to create a VM and it's pretty consistently under 75 seconds and it includes all the steps that I talked about before the network connectivity creation and all of that and our users are pretty happy because I looked this morning I had to look at the slide every day because that's the guy that disappeared we are reaching 800 VMs now so that's without advertising too much that infrastructure because since we didn't know how it would work we'd never really say open for business but people are finding out that there's an infrastructure where they can get machine for free so it goes very quick so what we have to find out now is how do we reclaim the VMs that are not used because since it costs nothing people might have two or three VMs that are running and they are not using them so we have to find a way to do some garbage collection and reclaim the VMs otherwise we are going to pay too much licenses to our vendors so what works and what doesn't work so the good thing is that if you are in an enterprise the first thing that you realize is that there are processes to change firewall rules and that there's an SLA to change firewall rules that can be between one week, two weeks depending on the complexity of the change so one of the benefits of this architecture is that we configure the firewall once pair class of service so the firewall has some specific group of policies that is identical in every colocation for a given class of service and we manage which VM goes into which network and therefore which class of service so the network security guys are very happy because they get to define the policies they get to control every package that goes through that firewall but they don't get the tickets every time we add a VM so they were very happy about that and that's a model that we are going to extend because it's making a lot of sense to focus on the policies we have the hard work to create new rules every time you have every change in the infrastructure so the network are pre-created so that's good for provider networks but for tenants we will do that dynamically we can use the same pattern to create different class of service we have the logic now to do that for example for the two or three other class of service that we want to implement as you can see as I said our stack OpenStack Ubuntu KVM worked very well for us we can compare that to something I did not mention is that already 50% of our infrastructure runs on our own cloud and we can compare the performance and scalability of our own cloud with what we have developed for the developer class of service and it compares very favorably so for us it's a proof that we can move to the next phase which is start deploying production use case on that infrastructure and there's an interesting feature coming up in 4SOM and Quantum V2 that we are anxious to use so that's very good and I think that that area of Nova is where innovation is going to happen sorry, this area of OpenStack is I think where the most innovation is going to happen because I don't want to diminish the Nova capabilities but there's not much happening in the hypervisor space you may add virtual VC for OpenVC for new hypervisor Elixi or Hyper-V but there's not a lot of new features that we can develop there but I think that on the network side there's still a lot that can be done and that's a very interesting area to contribute the bad thing as I mentioned in OpenStack you cannot do an assignment of network policy based so you have to let either the user define what nick they want to use for their VMs or you use the default policy which is every public network gets attached to the VM plus the project specific networks in SX there was only one network flavor you could only have one gateway if you use the Nova network the way we are using it so this has limitations because for example for two different class of services you might want to use two different routers connected to different firewalls and I think that in Folsom we will be able to do that scale out there's still one bottleneck which is the router or the gateway where all the virtual networks are terminating so today in our design we have one gig link but since it's mostly interactive traffic it's SSH connections it's not a problem but if we have for example use cases that require a lot of data out of their virtual network and that data resides on the physical network it has to go through that gateway like the North South traffic and that gateway is going to be a bottleneck so the NICERA team is trying to remove as much as possible this part of the topology the one thing that is complex is linked to the organization and policies that you have in big enterprise which is usually you want separation of concern between networking, security and the server management team it's either for compliance point of view or just for plain best practices so what's happening right now is you see that on that gateway server we have networking components we have security components because so we have a virtual switch we have rules, IP rules we have file rules and it's running on the compute server so who is going to manage that infrastructure is it the server team is it the networking team or is it the net-sec team so there's interesting challenges with network virtualization where you don't really know now who is managing what so I think that as we mature we'll find out the right middle ground but most of the time the networking team will say oh if it's not wrapped in a shipment and I don't want to manage it that's it will say oh it's not a file that I support so you're on your own and the server guys will say wow there's too many things on that works that I don't understand that I don't want to manage because it's networking, it's security and all of that right and it's understandable because now you have to have people that understand the three technologies so it's kind of the challenge that we have so what's next so we are going to implement different class-of-service additional one more like production-like one thing that we looked at is for production traffic we'll likely go to another model which is bridge network to avoid the overhead but since there's less and less overhead now with tunneling it might not be even relevant we have a bit more than 80 machines I don't know exactly how many machines we have today that are supporting the 800 VMs but we are going to increase this infrastructure to as much as possible I cannot tell the number because it depends on how many developers we have more gateways so we are going to move the gateways to 10 gig links so that we can have more north-south bandwidth available outside of the virtual networks we are going to integrate with Folsom and look at also integrating with some work that happens in the load balancing space and plug load balancers in that network so that we can have traffic coming from the internet through like a one-armed type of load balancer setup going on the virtual network through some floating IP to serve some typical front-end use case and we are working on a cleaner OpenStack integration which is what I mentioned before that Subu and Tim are working on which is moving all the parts that we had in our own custom cloud implementation to be in the OpenStack proper domain and at the same time contributing back as much as we can onto the OpenStack community to what we are doing in that space and last but not least we are hiring too this morning there was a question by Thierry I think how many people are hiring OpenStack developers and I think that everybody is but at least we are a bit different than the other ones any questions? Yes, I did look at it to be honest IP advisor choice, the controller choice was based on maturity so I'm sure that in a few months or a few years there will be more options right now I'm not paid by NICERA I guarantee you but they are the most mature solution and it's been proven so far I'm not saying that you cannot make Ryu or Midokura or other solutions work but with our scale requirements and our availability and reliability requirements we felt more comfortable at this point with NICERA so today it's only internal facing but the next phase that will be delivered in December is external facing too same infrastructure and the difference will be that each network each tenant network will be its own virtual network because we have a stronger isolation requirement because if one tenant gets compromised we don't want the other tenants to be compromised so there we will use private networks and we will control the traffic that goes in and out of each tenant network no villain segmentation, all virtual networks our network team said no villains there are too many issues with villains network segmentation yes they could it's still compatible with security groups the only thing is that they would not be able to grant themselves access to something that the perimeter firewall disabled and that's also something that is important is when I mentioned that security groups cannot really be combined together with provider rules is that if you give access to security groups and people can change any rules they want then you have to make sure that they cannot disable some provider specific rules and that's where having this separation is very interesting for us exactly, so there's provider security which is defined for each class of service and then there's pertinent security and if you don't want to expose your service for example your database outside of your virtual network you have two options you don't put a floating IP so no one can reach in or you put a floating IP and you select which host can access your database for example oh let me go back because I think it's maybe important so let me go back one more so there is let's take this example each VM is in the top of the rack environment which is like the leaf and spine environment but the gateways they are not connected in that leaf and spine environment they are connected directly to our core or distribution fabric because it's north-south traffic so there's no point of putting for example the gateway here and going all the way back to a firewall so our infrastructure is connected differently than our compute nodes and the other reason is because the connection between the firewall and the gateway is using villains so that's the only place where we have villains is that here I did not mention that but the orange link here is a villain so those two are two villains and the villain span is really between those four, six elements it doesn't go out and that's the maximum that we want to do with villains it's just like local villains if you want so if we spin out another collocation or another instance of that we can even reuse the same villains those things will not be connected to some trunks so we limit the layer to a span so the question is how do we create the gateway here so the NOVA network through NOVA manage when you create a network automatically NOVA network creates that gateway for you and it happens that because of the bridge compatibility it's using the same Linux bridge command to do that, BRCTL and under the cover this results in the creation of a NICERA port attached to your network so the question is how many machines and what are the upgrade challenges so today we have 80 machines so it's like 10 VM per machine I think we can go to 12 with our current configuration I don't know if we can go much higher the upgrade challenge that we are seeing is first the open v-switch is a kernel module and when you upgrade a kernel module you have to be careful not to bring down your VMs and have to reboot so the upgrade of that component here is a critical part you have to get it right the upgrade pass for the rest of the components is similar to any kind of open stack upgrade I guess you take a backup of your database and you hope that the upgrade scripts is going to do the right thing but I don't think that there are any more challenges we upgraded our infrastructure from Diablo to SX and multiple releases of SX up to the actual release and it went pretty smoothly I don't think that there was any specific issue because the Nissan infrastructure is pretty agnostic to what happens on the open stack side the only issue is the open stack components and so far it's been pretty easy to upgrade I crossed my finger and hope next time it's going to be as good but any other question? OK, thanks


Now if you guys missed out on getting Merlin's Cloak in Hogwarts Legacy, while you do now have another chance today I will explain all. As you've gone guys, my name is DPJ and if you're doing a new video, leaving a like really helps out and if you like what you see and want to see more, be sure to subscribe. Okay so Merlin's Cloak looks absolutely incredible, by far the best cloak in the game, no one's going to argue with that, but there's only like limited times you can get this thing the first time, you had to watch them stream for a certain while, they've stopped that now but they're actually giving you guys one more chance to do this, so you want to do this while you have this chance. They tweeted this out which you're seeing on the screen now, Legacy Live returns on the 5th of the 5th at 9am PT and so has Twitch drops, be sure to watch to get your Merlin's Cloak. And the reason they're doing this is because the actual game releases an old gen PS4 and the Xbox One, but this means guys if you play on next gen PC, wherever if you missed out on getting a Merlin's Cloak, now's your chance to get it. Now it says 9am PT but time zones are put on the screen now to match your country and the Twitch link to where they're going to be streaming this, you'll find also linked down below. Now there are a few other things you need to know about actually getting this thing and that is your Twitch account, you have to have a Twitch account, it needs to be linked to your Warner Brothers games account, both are linked down below, these must be linked together, then guys you need to use the Twitch loot drop page or the drops and rewards page which I'll also link down below. And you need to keep an eye on this while you're watching that stream because you will need to claim the rewards too, again that will be linked down below. Now when you actually have claimed the reward, when you've watched the stream for a certain amount of time and you have that Merlin's Cloak appear in your Twitch loot drops and rewards imagery screen and you've claimed it there, you still need to do a little process. Firstly make sure your Warner Brothers games account is a link to your playing game attack profile, whether that Steam, whether that's PlayStation, whether that Xbox, make sure it's all linked together. Then guys you need to use this page right here, if you've got to Google and write Hogwarts Legacy, Twitch drops, it'll pop up, I'll link it in the video description too for you guys, but this is the page you need to go to. Then all you need to do is follow the steps it states on screen. So you'll need to sign into your Warner Brothers games account and then connect your Twitch, this may already be done for you. You'll then need to click tune in which you're seeing here, but don't worry about that if you've already watched the stream for that certain amount of time, you'll be fine here. Again checking your Twitch inventory to track the progress of your claim, that's the page I already linked so you'll find there and then guys you just simply claim your rewards. And it really is as simple as that guys and then you will get Merlin's Cloak in-game. A lot of people are confused about this, I myself was as well and this solved it for me. So if you've watched the stream, you've linked all your accounts, you've claimed a reward, but it ain't appearing in your game, use this website and you should be good. And there we have it guys, but yes I believe this is the last chance of you being able to get Merlin's Cloak, so you want to do it while you can. Guys if you enjoyed the video leaving a like really helps out, if you like what you see and want to see more, be sure to subscribe and hopefully guys, I will see you on that next one.


are great about this that impact pretty much all of the items that we discussed today this is going to help us be more competitive for all those grants that poor tom is going to be writing I mean it's going to improve ridership it really I'm I'm just he's been making very heroic efforts yeah very appreciated okay mr hagan I'm sitting here thinking this is fabulous pull your microphone up I'm sitting here thinking yes this is fabulous but remember a lot of the riders on the buses are my age and older now we've got to do something to educate these people because you'll see they got the cell phone was sitting in front of them and you see them on that all the time and all the buses but use how they use it please have some form of education for these don't just throw it out there yeah thank you um yes mr Rothwell so we talked in a general way about how to publicize this program but do we have a specific program set up to publicize this or are we just going to talk about it in the kind of a general way and hope it happens well it would be a coordination between planning and or the team to have an outreach to and we have something in the works for doing that right now we will we will we have to there's no question about that it would be nice if we could have a marketing manager board to help us do that but the timing doesn't match as Isaac talked about if he if we get this out on the street in august and get it awarded and hopefully in the first quarter of next year have it installed that doesn't match what we did in the budget which is to hold back on the marketing manager until after november then i have to start a hiring process that takes probably several months they just don't match so we'll have to find those resources internally to put together a good plan plan um we do have that um uh we do have a contract with miller max field i always mess it up i mean just we'll use we'll use those resources again to help us get the word out he he's just done a fabulous job for us um and the price is right so we'll definitely do it will we get to see the end result of that presented here we i'd be happy to present progress reports on how we're doing i think that would be great yeah and then if i might i just i just really wanted to give some kudos to isaac well deserved he's been a very patient man um he's he's been ready and wanting to do this for quite a while a few years and he keeps coming to me and saying do we have the money and we've we've been patient he's built a spec and over the last three years he's probably had no less than what 15 or 20 vendors come to this property and present their wares and the beauty of that is it's not really about trying to become aligned with any particular vendor but just getting that information from them about what their product is what components of that product we like and don't like what's different from another vendor and then he's been able to build a spec that matches us what we need and it may not be any particular vendor it may be a vendor that has to modify what they do to meet our need so he's been patient he's done a great job um i look forward to getting this out on the street and and rewarding you with a installation yeah in addition i'd like to add i'm a member of the the cta it committee and so i'm in communication with colleagues in their experiences so i'm getting a little reference information on your experiences with different vendors and the pitfalls they may have run into i attend apt a transit tech i'm involved in apta so there is uh there's a lot of information there as well so i'm doing a lot of research math is so presumably goes out to rfq rf whatever and you have a way of building into that something about performance criteria and other entities um i think that would be more of uh i think that would be a question for procurement because they do have uh there is a boilerplate we can we can of course adjust that accordingly to uh it's not a bad thing to incorporate to the extent you legally can because i'm sure some people you know they look good on paper and yeah performance is not not so much detail erin could speak to that further if you like i i don't need it now but i to the extent you can build in something like that it's helpful to have it there as a factor yes thank you any comments from the public i would be happy to make the motion uh for the uh i know all enthusiastically second have a motion to second all those in favor aye aye so ordered okay i just want to announce two that uh thank you everybody you have copies of headways and news clips of uh recent uh weeks of uh metro activities um without any other additions uh we will have our next meeting on friday august 24th at 9 a.m at the scott's valley city council chamber in scott's valley this meeting is adjourned


Hachat Audio presents The Truth About Animals, Stone Sloths, Lovelorn Hippos, and Other Tales from the Wild Side of Wildlife, written and read by Lucy Cook. This book is dedicated to the memory of my dad, who opened my eyes to the wonders of the natural world. Introduction Can sloths exist when they're such losers? As a zoologist and founder of the Sloth Appreciation Society, I get asked this question a lot.  And sometimes the query is paired with the rider, I thought evolution was all about survival of the fittest, delivered with an air of bemusement or worse, a whiff of superior species smugness. Each time it happens, I take a deep breath and, with as much poise as I can muster, explain that sloths are by no means losers. They are in fact one of natural selection's quirkiest creations and fabulously successful to boot. Skulking about the treetops, barely quicker than a snail, and being covered in algae, infested with insects and defecating just once a week, might not be your idea of aspirational living, but then you're not trying to survive in the highly competitive jungles of Central and South America, something the sloth is very good at. When seeking to understand animals, context is key. The secret to sloth's extraordinary endurance is their lethargic nature. They are paragons of low energy living with a suite of ingenious energy-saving adaptations honed over many millennia and worthy of the most eccentric and gifted inventor. I won't launch into the full list now. You can read all about the sloth's innovative upside-down life in Chapter 3. Suffice to say, I'm a sucker for an underdog. The reputation of the sloth was sufficiently besmirched that I felt compelled to found the Sloth Appreciation Society. Armotto being fast is overrated. I toured a talk on the unexpected truth about this much maligned creature to festivals and schools. It traced sloth-based slander back to a clique of 16th century explorers who took it upon themselves to brand this quiet vegetarian pacifist, the stupidest animal that can be found in the world. This book grew out of those talks, and the need to set the record straight, not just for the sloth, but for other animals as well. We have a habit of viewing the animal kingdom through the prism of our own rather narrow existence. The sloth's arboreal lifestyle is sufficiently extra-terrestrial to make it one of the world-