Right. While everyone's still finding seats, I want to give a big shout-out to Blue Box. And the reason for that is that we thought we might be full this morning, and so we asked Blue Box if they would allow us to stream this presentation out to the video wall, and they very kindly agreed. We haven't been able to organize that with the OpenStack Foundation, but I still wanted to appreciate and give a shout-out of appreciation to the good guys at Blue Box for making that possible for us. So, we still have, looks like, five seats, Mark? Five. No, I think we're good. Early bird. Very good. Let's get started. Bienvenue. It is fantastic to be here in Paris. Oh, I'm so glad that's not the AV system. Right. It's great to be here in Paris. I want to thank the Foundation for choosing such a wonderful city. I hope you guys have all had a wonderful first day of ODS, first day and a half of ODS, and that the conversations here are everything that you hoped they would be. I must say that being in this kind of environment has really sort of raised the quality of thoughtfulness and the caliber of conversation amongst all of the different vendors and participants in the forum. Without further ado, I would like to dive straight into what will be an overview of a series of presentations which we'll be holding in this room over the next couple of hours. I hope to show you some of the extraordinary things that OpenStack is now capable of doing and some of the extraordinary things that people are doing with OpenStack.  Couple of folks. Okay, so we have a tradition, and that tradition is that every six months at ODS, we celebrate the extraordinary progress that OpenStack has made and also the progress that's been made in the Ubuntu community and Bio-canonical in terms of what OpenStack is capable of and also in terms of how easy we've made it to use by doing a live demonstration on stage of a deploy on bare metal of OpenStack. Now, this is why I am very gray because doing this every six months is somewhat terrifying.  Well, today is the summit of that journey and today is kind of a milestone for all of us because my little secret is that every time we've done it, we've never needed it, but every time we've done it in the past, I've had a safety net. One of my colleagues sitting behind the curtain who would be able, if necessary, if I pushed the wrong button, to quietly make things move forward in the direction planned. Now, we've never used that, but I've got to tell you, it was the only thing that kept my heart still beating as we went into canonical keynotes. Anyway, today I feel sort of relaxed about this because I'm not going to deploy a cloud and in fact none of my colleagues are going to deploy a cloud, but if you would be so kind, one of you will deploy an OpenStack cloud live on stage in front of everybody else. Now, to make sure that this is not a plant, I'm going to ask someone to throw a hopefully not very well-made paper aeroplane into the crowd you don't look like. Throw it anywhere you want, any direction. Hopefully it won't go very far. And if you work whoever receives it, and so moving right along, go ahead, however you want to pick a random volunteer, and if you, live demos, ladies and gentlemen, all right, all right, all right, I tell you what, wait, wait, wait, I think we can improve the aerodynamics of this structure mainly by doing this and just throwing it that way. Now, if you work for canonical or you know what's coming, then throw it away, pass it on. You don't, you want to come up on stage, you don't have to come up, pass it on anyway, why not, throw it in a random direction. You going to come up? Ladies and gentlemen, tell us a little bit about yourself. My name is Russell. I've recently moved into the world of IT infrastructure. I work as a systems engineer, so I'm just sort of getting into understanding what Clown's all about really. Sounds good. How are you liking Paris? That's good. All right. And have you ever compiled your own kernel? No. Brilliant. Okay, so have you ever installed OpenStack? No. Brilliant. Would you like to? Are you nervous? I've got to tell you something. I'm nervous. But come over here. Let's have a look. So have you ever been to Texas? No. All right. So I'm going to teleport you to Texas through this thing called the Internet. It's a system of tubes. Okay. Not there. Here we go. So this is the University of San Antonio in Texas. University of Texas in San Antonio. And they're very kindly made available to a 76 machines of all sorts, just random hardware.  There's some AMD-C micro. There's an AMD-C micro chassis in the mix over there. But it's a nice healthy random mix of stuff that we could cobble together. And all of those machines, except for one, are switched off with no operating systems installed. And in the course of the next little while, you're going to build an OpenStack cloud. How's your chef? Non-existent. How's your puppet? Same. How's your web browser? I can do that. All right. Good. So that's Maz. Everybody knows what Maz does. Maz is metal as a service. So it essentially just does all of the pixie booting and BMC management and operating system installation, all of that base data center management stuff, like software-defined infrastructure. And then on top of that, normally we would layer juju to orchestrate all kinds of different things. But what we're going to do here is point the canonical OpenStack controller pilot, which is here, at that Maz. So just zoom out a little bit. So this is Landscape. It's our standard systems management software for Ubuntu. And this is the now in beta, now in public beta OpenStack installer. So all we've done is one of those machines is switched on and it's got Landscape installed. And we've pointed it at Maz. And you can see that down here. So it says we registered a Maz region controller. We've got at least five machines in there. And at least one of them has multiple disks and multiple network connections. That's a whole neutron thing. Right. My only clue is that that button over there starts the process. Right. If you have to ask any questions, ask them. I'm not allowed to say anything. Okay. There you go. Good choice. So this is an interesting thing, right? That's not from browser history. That's Maz, which knows the network and server layout and it's telling Landscape, these are the networks you could use for your public gateways. And it knows the IP address ranges, so it's telling him which ranges will work for his external neutron gateways. Oh, you guys are so boring. But it's a good choice. Don't get clever now. All right. So what's happened is Landscape has gone to Maz on the list of all of the machines that Landscape thinks could be useful for this cloud and they're preselected. So you could deselect them or you could leave them all there. Depends how big the cloud is that you want to make. Up to you. Oh, big cloud. Okay. Don't ask me. Voila. Now, thank you very much, Russell. That's all there is to it. So that software is available now.  You use a standard script to deploy Landscape on that and then you point Landscape back at Maz and you can use the rest of your hardware to build an OpenStack cloud. Now, the reason we've done this is because right now OpenStack deployments are largely limited by the number of OpenStack consultants in the world. Consulting is really expensive, right? And it's expensive twice. It's expensive the first time when you get those consultants and you have to get the good ones and you have to get them on time. And then it's expensive every time you want to upgrade or change that cloud. So what we wanted to do is to say for folks who trust us to build a great reference cloud, we wanted to be able to automate that process so that you can do it in your own data center with no consulting whatsoever. So we really dramatically reduced the cost to people of just getting a standard reference cloud. Because that's built into Landscape, of course, it also comes with all of the management, the systems management for those underlying hosts and guests, the Ubuntu hosts and guests. You would use your normal management software for other operating systems that you mixed in. And there are a couple of cool things about that. We will evolve that reference architecture. Now, our reference architecture at the moment, we're going to do a walkthrough of that reference architecture at 5.30pm here today. We'll share everything that we've learned about how to do a great open stack deploy. We've done this at some of the very largest institutions of the world. And we'd love you to reproduce that on CentOS or REL or SUSE or VMware. Any platform you like. So we'll share what we've learned. But we wanted to encode what we've learned in a place where people could just say just give me what canonical knows. And that's what this autopilot is all about. And the cool thing is as we learn more, we will update that, you update Landscape, you push the button and your cloud will evolve to the latest, greatest reference architecture. So I think that's pretty cool. The problem with reference architectures and standard products though, is that they tend to limit the number of choices you have. And I hope you saw there, that in fact we've started to give people all the commonly trusted choices in open stack. And of course we want to extend that because we want this to be a reference architecture that is uniquely flexible and customizable and shows our partnerships with a number of vendors in the world. You may have heard of Oil, the open stack interop lab. And I'm delighted that there are now 26 global vendors who are part of the interop lab. And what we do, there's a talk a little bit later I think that's at 340. I've got times over here. Sorry, that's at 250. What we do is we build the open stack 100 different ways every day. 3,000 builds every month. We run 32,000 tests of open stack every day in this interop lab. And as these vendors code essentially goes through that validation process, at the end of that we will certify it. And if those vendors want, we will add their code, their plugins, their extensions and so on to this reference architecture standard installer. So you'll be able to make the choices that Russell made, except you'll have a bunch more options. And I'm delighted to give you a preview of open contrail from Juniper, which we expect to land in this autopilot just in a few months time. So during the course of the cycle. If you look at this list of Oil vendors, one of the things that I'm really proud of is that we really have attracted a lot of the SDN vendors to Oil. And so we really are serving as a platform for interoperability testing. We're able to say, okay, for a given SDN, let's test all of the storage options, let's test all of the hyper-arviser options and the permutations and combinations of that. And then give feedback to those SDN vendors as to their interoperability with all of those other choices that you might make. And that's come about because of a strong focus on our part on the telco market. There is a talk later on today at 340 here on SDN and NFV. So those of you who have heard a lot about NFV, but are interested to see live demos of telco applications being deployed, live on to clouds which you can interact with, show you a little bit of the work that we're being asked to do on behalf of telcos to help NFV vendors integrate their stuff with each other. We obviously use Juju for live integration and deployment on to OpenStack and any other cloud or bare metal. And all of that will be deep diving on SDN and NFV at 340 this afternoon. Okay.  A year ago in Hong Kong we talked a lot about the telco industry because at that time we were seeing telcos as the lead investors in OpenStack. And that's really why you see such a strong SDN presence on Ubuntu and with Canonical and strong NFV presence there. Then six months ago we talked about work that we were doing with the banking industry and I'm delighted that those projects have continued to grow and we're now well represented. Oh, sorry, I should say we've had a bunch more telcos during the most recent of which was WingCloud in China and we're delighted to have them on board as a partner. In banking we've continued to grow and we now have a number of projects on Wall Street and in London and around the world and banks really are pushing our security story forward to ensure the complete isolation of the infrastructure from workloads and so on and also pushing performance. We've done a lot of work with the banking industry on containers and OpenStack and I'll talk a little bit more about that later. But in the current phase what we're seeing that's really interesting is tremendous acceleration with media companies.  First, their workloads are typically very scale out friendly a lot of transcoating a lot of streaming and they're also a great fit for juju because if you think about what a TV station does it's launching new shows and properties every quarter and you never know which of those is going to be a hit so you'll have huge amounts of traffic which of those will be a miss and not have a lot of traffic you don't know if they're going to last a year or 10 years and so you need a really elastic infrastructure and you're doing repetitive work setting up for each new show websites, SMS gateways, competitions forums, fan sites and so on and so that repetitive rapid deployment of best practice stuff is really a great fit for juju. I wanted to highlight one of our customers and partners, folks who've taught us a lot in the last couple of months and who's focused on scale out, I've really come to appreciate and that's Sky. A few words from Sky about their engagement. One of the fantastic things about Sky is we continue to innovate and push the boundaries in the way that we bring products to our customers and bring content to our customers. When we started our private cloud initiative we wanted to be disruptive for a number of reasons but principally we wanted to pick a selection of technologies both from hardware perspective and software perspective that were best in class that would make sure that our cloud was designed from the ground up to be what we wanted it to be. The main characteristics we were looking for is a sustainable cost base so price tag for the cloud platform that makes it effective and viable at scale. We needed a platform that was obviously robust and scalable and also a platform that brings innovation and a fast pace of innovation around open stack. Ubuntu helps us meet those and more importantly realize those because of that broad range of experience that Canonical bring to the deployment. Canonical has helped us understand how we engineer those characteristics into the platform from the ground up and then how we most importantly maintain their moving forward. To look at the risk is also key so for us OpenStack it was risky there's many successful deployments but there's also many failed deployments partnering with Canonical and Ubuntu bringing their expertise with our own engineering teams would ensure that with the risk of project as much as possible. Jujo and Mass are critical for helping us build and deploy and manage the cloud environment because automation is one of the core benefits and core objectives of us from our private cloud initiatives. Without tools such as Jujo and Mass we'd have more people doing things more manual processes, more manual tasks. So having this ecosystem of tools to help us deliver automation all the way through from turn to software is critical. Now the name of that project actually is the linear scale data center and I think it shows the insight that they have they really are trying to restructure their operations to fit the economics of the 21st century and the wisdom there was lots of interesting stuff there but he called out economics and this is something that we think a great deal about OpenStack is really only going to work if it is economical in the 21st century for people to run private clouds there's a hard limit because of the public cloud and the excellent work that's been done in the public cloud there's a hard limit on the economics for OpenStack we try really hard to walk a fine line we know we've got to be sustainable we know we've got to be able to make long term promises to customers we also know that those customers have to be confident that in the long term the economics of building on OpenStack with us are going to be highly competitive and advantageous to them compared to the public cloud and that's a really good discipline to have I think in many ways so I want to give you a little bit of a map of the way we engage with folks around OpenStack today that's not it that's not it either you know what I magically hit the wrong key this is like an IQ test and I don't think I'm passing but I pressed the right button so the first thing we try to establish is whether somebody is really focused on the cloud as the opportunity in its own right so for example telcos who are going to offer cloud services for them being way ahead of the curve on the cloud itself is really important and those are kind of like formula one type engagements because really with them we've got to learn a lot we've got to push forward on the science of the cloud of the scale of the cloud on the other end of the spectrum we have folks for whom the cloud is merely a way to ensure that they can continue their operations in the security of their own data centers and their own environments and so really that boils to sort of on the spectrum of tending to reference or tending to the extreme so on the reference front you saw the autopilot right so our goal there really is to reduce the costs of a reference cloud to simply the cost of supporting the Linux platform so that's either 300 to 700 dollars a node or AZ pricing which we've announced previously 50K depending on the scale of your AZ but we know that we have to cap that cost because you're thinking about private versus public cloud for folks who have a short term skills blockage we also then are willing to actually build the cloud and operate the cloud until they have the team to operate it themselves and so this is proving a very useful bridging function right so boot stack build operate and optionally transfer a quick way to get a standard reference cloud up and running have us handle all of the backups and other operations all the monitoring while you staff up your open stack skills base either internally or recruiting and then we transfer the keys and pull out our engineers so that's all handled in your data center remotely on your hardware and again that's 15 dollars a day or 5000 dollars per node for a full year typically those are three to six month engagements while people ramp up and build their their cloud for folks who want to go beyond the reference we kind of break that into two categories we think of it as tailored in the tailored case really what we're doing is we're accelerating the roadmap so say for example you want to work with an SDN vendor that's not yet in oil or work with an SDN vendor that's not yet in the auto pilot that's where we would go there and essentially what we're saying is we'll do that necessary development for you at cost in our interest to accelerate what would be in our roadmap anyway for the formula one guys it's a much more intense engagement we have onsite staff this is where I think consulting actually makes sense doesn't make sense if you just want a cloud to run your workloads it makes sense if the cloud is your business and you want to be ahead of the curve on the cloud so we're trying to make sure that we're only engaged with consultants and our partners are the sorts of consultants who can handle these formula one type engagements right people often ask what our focus is in OpenStack and I hope I hope you would agree that we've tried to be really thoughtful about where we go in OpenStack and what we work on at OpenStack and this is how I think about it what we have to prove to the world as an OpenStack community is the performance reliability and scalability of OpenStack that is the question on the table now can you get to 500 nodes, can you get to 5000 nodes, can you get to 50,000 nodes that's the question that's on the table at the moment and that's really where we focus all of our energy and I think OpenStack is at a really important decision point in what it wants to be there's really deep questions at board level about what is the focus of the project I think this is the thought that I'd like to share I think it would be very good for OpenStack to strongly say that the core of OpenStack is these four pieces this is where we've focused and the reason for that is we think everything else will come in time everything else will come in time there are dynamics inside the project which are I think bringing too much code which has knock on consequences for that core bullshit as a service money as a service, junk as a service irrelevant vendor bluff, puff and distraction and so we as a company are trying to focus very strongly and work with other people who focus very strongly on that core because if we get that right then all of the innovation that's happening on EC2 and on other public clouds will come to OpenStack and so we're not going to beat all of those startups with committee meetings we're going to make a viable platform that brings that innovation to the private cloud that's the way we see it I hope folks appreciate that to work on that core to work on the performance and reliability of that core is ten times more work per line of code but I think it's ten times more valuable per line of code to give you some taste of the sort of stuff we do there every six months we do a scale out performance test of the current release of OpenStack and then benchmark that against previous ones to see how we've done and in this round we've got partner HP thank you very much HP for making available a series of moonshot chassis these are amazing hyperscale very dense new style new architecture devices very dense x86 and ARM cartridges so we did this benchmarking on x86 and we were able to deploy the cloud itself on a couple of hundred nodes 500 odd nodes in two and a half hours which is a lot faster than we were able to do it six months ago we were able to hit 100,000 vms which is our target threshold in half the time that we were able to do it six months ago so that's pretty good news the other really good news is that neutron has gotten much more scalable between Icehouse and Juno so this is Juno that I'm talking about and that autopilot that I showed you that's Juno as well so if you use the autopilot you get Juno M and beyond so that's the good news neutron is much more scalable there's still work to be done there particularly in that neutron doesn't support cells so at the moment there is a hard limit on how far you can get but within the bounds of that it's much faster, it's much more scalable the bad news is we saw significant regressions in Nova in Nova scalability so we've got some patches for that we will apply those patches to the stable branches of Juno that we co-maintain and we will make sure that everybody gets those they are or will be in a Buntu open stack as well so they will be part of the autopilot installs that you do but I think it goes to show that when you've got development moving very fast and we've got many many many topics of conversation when you've got many of developers working in kind of artificial environments like DevStack that these scalability issues can creep in without anybody noticing and so we know that if we're doing continuous integration every day for correctness we now want to look to do continuous integration every day for scale take this sort of infrastructure and make it part of the CI CD process to help catch those issues in open stack very very early right so that's it for open stack for the moment but what are people doing on top? well who's heard of Docker? anybody not heard of Docker? okay Docker is amazing it is profoundly changing the way developers are pushing code into production it is the fastest cleanest neatest way for your devs to push their code into your production servers and I think it's amazing and kudos to Docker Inc for the work that they've done there I think everybody knows that Docker was born on a Buntu and we continue to work really closely and we work not only with Docker but we're very passionate about the developers who are using Docker so there are actually six times as many Docker images on a Buntu as they are the next operating system in the list and that gap is widening because we continue to focus on whatever we need to do to make a Buntu great for developers so if you happen to be a developer in an institution which is fascinated by Docker but has a corporate policy that limits you to shall I say a legacy Linux environment you will be delighted to know that this is the new way for a Buntu developers to get their code straight into production. We're seeing that all over the enterprise market as well one of my sort of passions is all of the things that are growing up around Docker and we're seeing a whole explosion of different ways to command and control Docker environments there's days there is flocker there's a fig from Docker Inc itself panamax from Century Link fleet from the great CoroS guys there is Kubernetes from Google Diego from Pivotal this is a fantastic Cambrian explosion of innovation and we should relish and celebrate it and I want to make sure and OpenShift who've said that they're going to rewrite again to use Docker now all of those with the exception of OpenShift have chosen a Buntu as their target platform of choice and I want to make sure that all of those are available to you on a Buntu and not just on a Buntu but instantly deployable with Juju and I'd love to have OpenShift as well now yesterday we announced that we were working with Google to put a Buntu, reference images of a Buntu fully optimized on the Google Cloud which is a great milestone for both of us there's been a lot of fun working with Google and today I'd like to show you the fruits of that collaboration which is Google's optimized Kubernetes which I'd like to deploy for you live on bare metal I don't think anybody's actually done this before until we did it and certainly not in front of a public audience so on this orange box remember inside here we've got 10 little Intel microservice so I want to deploy live on stage Kubernetes to those boxes one of those boxes is actually it's a VM on the box that's running MAS is running Juju so that's the Juju GUI I'm not going to use the command line at all because Kubernetes is already in this repository over here so all you have to do is spin up Juju on bare metal or on Azure or GCE or EC2 or OpenStack you get this screen you go in here and search for Kubernetes here it is orchestration actually looks like and hopefully if I press this button you'll start to see lights coming on touch wood on this machine over here and that will be MAS being asked to provide metal on which it's been asked to put Ubuntu we now have banks deploying SUSE with MAS and other banks deploying REL with MAS and yes I'm glad to say banks deploying Ubuntu with MAS and soon banks deploying Windows with MAS as well anyway in this case MAS deploying Ubuntu onto new metal that's being requested over there and then Ubuntu being installed onto that metal and Kubernetes being installed onto that and while we're waiting for it to come up oh you know what I haven't done I don't think I've actually kept it off this is where the man behind the curtain might be really useful we'll come back to that one right so Docker is absolutely amazing and you're going to see an explosion of Docker command and control systems and we're going to put all of that on Ubuntu make it easily available on every cloud juju deployable and with packages in Ubuntu but what else well a lot of people a lot of the one of the most exciting topics of conversation generally at the moment is around containers and many of you may know that canonical leads the work at linuxcontainers.org which is where LXC the general system container is developed so I want to talk a little bit about what's coming there I want to announce that working together with that community canonical is going to lead the next big thing which will be a new hypervisor purely focused on containers called LexD now I'm calling it a hypervisor for a very specific reason the things that you count on from a hypervisor are security well canonical has led a Mac based security and second security and username space is security for LexD and we're bringing all of that to LexD in addition we're working with silicon vendors to provide hardware guaranteed isolation of containers so that all of the hardware guarantees that give you isolation guarantees in the chip in KVM will also be available to containers without the overhead of virtualization and because we'll be LexD we'll be a demon a small demon written in Go that runs across many different machines we'll be able to do live migration of containers from machine to machine now in the spirit of taking our lives in our hands if you want to see that in action stick around in this room because at high noon Tyco and Dustin are going to take their lives in their hands and do a live migration of Linux containers from machine to machine it's an awesome awesome demo so that's a taste of the future this is going to unleash new levels of performance for private clouds that are Linux on Linux the one catch with containers is that it's Linux on Linux if you want windows we're glad to give you windows which you'll have to put it in either KVM or ESX which will fully support as well so LexD you heard it here first ok so clouds well people don't build clouds I don't know about you but I don't think people build clouds because they like to see the blinking lights and thank God the lights are blinking so yes we're starting to get a bit of Kubernetes that's where it was so I don't think people build clouds for the blinking lights right they build it because they want answers they build it because they want solutions and so that's really what we're focused on now working with multiple vendors that's Kubernetes but in telecoms there's a whole portfolio of solutions NFV and otherwise that we're being asked to accelerate the integration of and deliver with juju onto clouds in a telecom type environment in the media environment it's the same and the one thread that comes up is customer engagement one is big data and so I'm delighted to announce that over the next six months we will bring to market solutions from three of the biggest big data companies in the world MapR Hortonworks and Cloudera and of course we're going to deliver all of those as a series of juju charms so that you can deploy their solutions instantly on any cloud now the really cool thing about this is I gave this presentation of this to a financial industry technologists event in London and at the end I showed MapR and Horton and Apache Hadoop just spinning up the end of the guy put his hand up he said look I don't have a question I just want to bitch about it he said because if I'd known this six months ago I could have saved myself the last six months because I've just spent six months deploying all of those solutions manually and here we have them deployed instantly on any cloud or on bare metal so for evaluation purposes all of them have strengths that might lead you to choose them for your particular application for evaluation purposes this is going to be absolutely the best way to choose your big data or Apache Spark solution of choice we're also working of course with application vendors who are delivering intelligence on top of Hadoop also as a series of juju charms and those are going to be demoed later today over here that will be in this room at 4.40pm so cloud foundry working with Pivotal and Hadoop working with all of the lead vendors now I want to call something out here our goal is not to sort of muscle our way into these markets and compete with those vendors I don't know about you but I really don't like it when a platform vendor feels it has to buy or compete with people who've originated the technology because innovation is hard platform companies tend to have other problems and so they don't innovate as much so I feel we have to accelerate those companies and we have to let them bring their solutions to market we have to let them compete and let them innovate so that's our agenda we're not entering the cloud foundry market with a canonical cloud foundry we're supporting Pivotal and we'll support other passes and other institutions as well we think Pivotal has the leading enterprise solution with Pivotal cloud foundry but we want to see all of that innovation happen so we're not going to try and crowd it out we want to accelerate them getting your ability to evaluate and choose their solutions and their ability to find customers whose expectations they can really really meet okay most clouds start with a particular application in mind and I think that's really really good because if we know what your application is we really can tune that architecture to accelerate that application but one thing I've observed is that a cloud gets built for a particular purpose and if it's successful the same developers then start to want to use the same cloud for other applications and so there's kind of a trade off because on the one hand you will get better results better performance and so on if you optimize the cloud for your application you know if you know you're doing Hadoop or you know you're doing Condor or you know you're doing test and dev then you would build a particular kind of cloud but the reality is that over time you have to be able to evolve to the general if you're going to be successful and that's just one of the great things I think that we've developed is the ability to to build a cloud using sort of mix and match components with the architecture the spread of services on metal that you want that's right for that thing but then to evolve it over time to be useful and important characteristic I think we're running out of oxygen in this room so I want to wrap up with an invitation to you and to your friends and colleagues it's a great privilege for us to working with Juniper I don't know if there's anyone from Juniper in the room but thank you very much for joining us in this to host people and invite people from OpenStack to one of the world's top five and I think top one art collections in the Musée d'Orsay which I've probably mispronounced but it is an extraordinary place and there'll be no decks or pictures champagne on Juniper and there'll be guides if you want to learn a little bit about the masters but in an evening before dinner, before the other parties you'll be able to see some of the art that you've almost certainly seen throughout your life incredible artists from an incredible diversity all in one place so I hope you'll be able to join us as partners, spouses, friends and I hope you'll have a lovely evening together anyway, thank you very much right after this right after the break actually I think we have time for questions which is the one thing we never had in a plenary keynote do we have time for a question? well, we've got a man with his hand up, go for it right, so I think the question is how are we going to make OpenStack something that works well in a newly competitive environment and especially if we're partnering with vendors that are perceived to have expensive solutions so the first thing is we're very mindful of the costs that we inject into the equation so we've tried to model those as being costs that will keep you economically productive on a private cloud in the face of competition from Microsoft, Google, Amazon Facebook, Tencent and other mega data center operators so we're very confident that our costs the costs that we inject will keep you well below the threshold in the face of that competition other vendors that we introduced to that I think are responding very well to the changing dynamics, you know, at times change technology changes, the rules of economics change and companies change as an example of that, you know, Microsoft I think is sincere in their commitment to running Linux on Azure right, that's an extraordinary shift not just from the leadership although I think it does come from the top with the support of the top but also from the heart of the business now I expect that all of the vendors that you saw on that page have plans have strategies to be able to offer value right, they know that if they don't they won't be around and our job is simply to make it really easy for you to evaluate their solutions choose the ones that work for you including on the economics and then build a reference cloud that includes those components fully managed to keep the costs down great questions Chris I don't know, has it Kubernetes is up those are the maz, if I just reload that you'll see a bunch of green those are the maz machines I'm going to go and I'm not going to do that I'm just going to go and scale out Kubernetes quickly another if we've got another machine right, so we just asked for another machine for Kubernetes and that is the cloud installer in Texas progressing, so what it's currently doing is deploying RabbitMQ, deploying Keystone Sephrados Gateway, MySQL OpenStack Dashboard, so it's spun up a bunch of those machines, it's got the operating system on them it's now allocated which ones it looks at the RAM, the number of cores the number of network interfaces, it dynamically allocates the right interfaces to the right kinds of machines, it builds our reference architecture and it's busy doing all of that it will probably take another hour or so, because that's 76 machines and not all super fast but when it's done that will be a full reference cloud and you're welcome to come and bang on it from our booth in the trade share area any other questions, I think we're out of time last question, so first it's not LXD, that sounds like a drug it's LexD LexD, LexD good, LexD will come out over the next six months we're doing this properly as a full open project it's written in Golang it'll be commits to the standard LexC LexC, nerdy, LexC LexC repositories under linuxcontainer.org alright, thank you very much, have a great day I hope you understand this


So, today we're going to discuss some probability and we're going to talk about conditional probability using a two-way table. So the table, it's on the next slide, I'll show it in a second, shows the number of survey subjects who have received and not received a speeding ticket in the last year and the color of their car. We want to find the probability that a randomly chosen person A has a speeding ticket given they have a red car and B has a red car given that they have a speeding ticket. So we're going to look at the data now. So this column represents speeding tickets. So there's 15 red cars who have received speeding tickets, 45 non-red cars that have received speeding tickets and then 45 plus 15 would be 60. There's 60 cars total that have received speeding tickets. Then we have 135 cars that are red that did not speed, did not get a ticket when they sped 470 that have not been ticketed that are not red and then 470 plus 135 gives you the 605. Then you can look at this row for red cars 15 plus 135 gives us the 150 and then this row for non-red cars 45 plus 470 equals 515. Then this two-way table we went ahead and did 60 plus 605 to get the total number of cars surveyed and you could also get to the 665 by doing 150 plus 115. So the first question here, we're looking at cars that have a speeding ticket given that they are red. So for red cars we're going to look at this row right here. There are 150 total cars, total red cars, see red and red, okay, 150 total red cars of which 15 had speeding tickets. And if I wanted to write this out with probability notation, I would say we're looking for the probability that a car has been ticketed given, we draw a line to represent given, it is red. So the probability that a car is ticketed given that it's red is 15 over 150 which would reduce to 1 over 10 or 0.1. Moving along to part B, part B says the probability that a car is red given that it has a speeding ticket. So we're going to look at the cars that have been ticketed. There are 60 cars total that were issued a ticket of those 60 cars, 15 of them were red. If I wanted to write this out with probability notation, I would say the probability that a car is red given it was issued a ticket, 15 over 60 would reduce to 1 over 4 which would reduce to 0.2.


Hey, welcome. Okay. So welcome everybody. This is the Sorry, this is the okd. I want to get their total right. This is the okd working group hybrid meetup and Your hosts today are going to be Christian Glomback and Vadim root house Rick Rydkovsky Christian is an engineer at Red Hat He's working on open shift. He's an open shift specialist He's no on the open shift specialist platform team and a member of the okd working group Vadim is a software engineer at Red Hat and that's all he wants to say about himself But I will say he's also a tremendous engineer and he knows open shift and okd topped about him So without further ado Christian and Vadim, please take it away Thanks, Mike. I hope my audio works fine now. I had issues earlier. Yeah, not sure what that was about So we haven't really prepared any special agenda, I think so It maybe we can kind of as we always do in the working group meetings give a quick engineering update where we're at And then kind of make it an open-floor session I was hoping that there might be some questions or you know people wanting to talk about what they're doing with okd So really yeah, but would you be able to give a quick update on our current? Yeah, sure. I mean last time we met on DevCon we did this tour. I think it's useful to look back and see Describe our progress for the whole year. It was a very very fruitful year for okd mostly because we were committed to staying along with features of the OCP Alliance and We still had a few packages forked which is installer and MCO Quick critical for the cluster lifecycle and we're working a lot with internal teams to Be shorted in this gap and now installer is fully coming from upstream We are getting the fixes OCP is getting immediately into okd And the very same story is happening with MCO. We have just merged our final Fix we need and now we can use upstream version with MCO with one small exception, which I'll cover slightly later Next I remember in the summer we did Short okd conference. That was very very exciting. We have multiple tracks where folks were describing how they using a goody with folks from University with a quite large scale of Usage and different kind of types of users I was participating in Home server type of stuff where you are tailoring okd for your own users Usually, it's just one note with additional workers is one. It was very exciting to see how They okd usage for eyes across different people coming from there Next we were working on a largely delayed feature of bare metal API and it should be available in 410 now We don't have a great set of resources to check this out in CI So we would be relying on people's feedback and Drive there, but the idea behind this is just to stay Stay same as to have the same features as the OCP has Now for the current state our actively Stable version is for nine. I don't think there has been quite Significant set of changes for The set of changes since last release. So we're mostly staying there the only Problem which we now have is that we're still using the door 34 because of Combination of Kubernetes and cylinder Xbox one conformance test is Failing on the door 34 right now. So we need to rebase to Kubernetes one 225 I believe and so which is supposed to be happening in a couple of weeks But we're being quite conservative there and we would rather deliver a stable platform for the users than crash within your features Meanwhile, we're cooking things which are coming in for 10 before 10 has been released to Kubernetes one 23 We have the fix and we were able to update to the latest for door 35 One of the interesting kind of features we have delivered this year was C Groups v2 by default previously the Fedora CoroS switch to C Groups v2 for quite a long time ago, but the Kubernetes upstream has been lagging for a couple of years and before C Groups v2 was Even supported and then ready to use and now we have transparently switched the new installations into C Groups v2 Since there are no additional features which this So which brings it should be fairly transparent to our users, but that opens the road for more interesting things like Limiting pods by IO consumption, which C Group v1 does not support but C Groups v2 support So we need is a Support in CRI for this kind of a feature another interesting C Group v2 thing which will might be available soon is Apart from mean and max there is also I believe it's something like medical So so setting for a memory where instead of just request and limit you can also set up Threshold where your application is supposed to start garbage collecting its memory It's incredibly useful for Java applications where instead of fully crashing You just tell it that the app is using way too much memory. It's supposed to start garbage collecting that's supposed to Help barcloads to be more resilient instead of just crashing with the OM it would start cleaning the memory and for 10 I mentioned that we're based to the author to fight and The bare metal IPI is coming there that should help folks who have access to IPMI and ILO and use these kind of a bare metal installations as an IPI target instead of UPI previously Also behind the scenes we're working on Some more features the most interesting from my side would be assistant installer that's a tech preview and OCP now, but incredibly exciting for marketing users in short, it's a it's a web app Which is able to generate a so-called discovery ISO When you boot your machine from the discovery I so this machine would be added and show up in the server And where you would be able to pick? the role there and Say this machine would be master this one machine would be worker That helps you to find issues with the configurations before the installation has started say Your resources are insufficient and the application will tell you immediately about that or your network and hostname a very very common case of failed installations are wrong so That would be immediately showed up before the installation has started Another bonus with assistant installer is that it doesn't use separate bootstrap note Instead it uses one of the masters even if it's a single master as a bootstrap note so So called bootstrap in place is already implemented as a part of the Assistant installer there is some quite some work we need to do with the installer and as it's installer folks as well but That feature is definitely what we would be paying more attention in the future Just to add to that. I'm incredibly excited about the assisted installer as well And it it's especially useful obviously for bare metal But it's also interesting for use cases on platforms that don't really have Fedora Koro as support yet You can kind of just if you can get the image to boot on a platform You can use it and the the agent really makes it easy to to figure out those issues because it will talk to the To the assisted installer service, which is the web the web app Which there is one hosted by retta, but you can also deploy that yourself if you want to host your own service there And yeah, that that is really great and hopefully that'll make it much easier in the future to onboard new platforms That don't have very tight integration with other parts of open ship yet It's a good. It's a really great starting point for those platforms Yeah, I would say that it's something in the middle between a fully customized UPI installation where you control all the things, but you're also responsible for them to be valid and Fully automatic API so you get both the best of the both worlds There is also work happening about arm 64 builds, but I think Christian could speak about more about that There is actually a another talk starting in 15 minutes by the CI folks Touching them is exactly that the multi-arch in a human for our prowl build system So if you want to learn more about that specifically, I Suggest you join that talk in 15 minutes. Otherwise, I can just say we're working on it We have our down stream build system actually already building that which is why we have an OCP Open shift that preview for 4.9 aren't already For okD. We use the prowl upstream Build system and that is currently not yet to be enabled for harm We have a cluster build farm that we will be able to use and hopefully soon I will be able to to push out those first builds I think that's all from my side about the status and the general state of things Do we want to help into questions open floor type of things or we have Yeah, sounds like open floor is a good idea Yeah, and I will let our viewers know that we have opened we have started a couple polls To kind of get some information about if you're using okD And if so how you're using it so please take a look at the polls to and yeah Feel free to add your questions in the chat here It's like it has been in the morning again, yeah, it was getting a little kind of scratchy there for me Christian So it looks like we do have some poll results coming in And so far we've got four votes for yes currently using okD and of those We've got three votes for bare metal and one vote for public cloud From what our telemetry tells us that's very very different I would say but that's the only data we get so This is the only thing we can base our decisions on but the Domination of the bare metal is very very evident everywhere. Yeah Yeah, well, I I will be the spoiler here. I do run okD in AWS and GCP. So Yeah, that's I'm outing myself as the I tend to run it there when I'm testing things and whatnot and trying things out So for me, it's like those those pathways work really well, but I can totally understand why our community You know loves bare metal and loves vSphere and whatnot because you know, those are those are great deployment platforms Okay, I think I've added you Christian I'm I I really only have one button on the interface here. It's a little green plus button So like I guess that's what I'm supposed to click So Vadim while we're while we're here like I'm I'm super curious about the C groups v2 stuff And I know I know you just went through it all but like at a really high level You know as a user, what do I get out of like pushing to use like C groups to and everything? Like would this be noticeable to me as an operator or an end user and at this point yet well exactly the same experiences you get with C groups you want because You are limited by CRI interface If you want to do a bad thing you can get your hands dirty and actually adjust The C groups v2 things of the containers in the loyalty spawn but the Kubernetes and open chip will be totally unaware of that The best part of it is that the road it opens We're using a modern kernel interface meaning we get more features. So eventually the CRI interface would start evolving and folks who already on C groups who to get additional features like IO block Limiting IO is basically what people want at this point And so on and so forth the C groups we want would would start fading away Just like we have seen with the docker, but at this point they have feature parity because C groups v2 CRI interface is very strict and I guess how does that? So how does that mesh with the concept of people wanting to start running like Kubernetes workloads on like Windows Clients and whatnot like is there any feature parity mismatch between the C groups functionality that Linux provides And what perhaps Windows is providing through its container run times. This is this is basically the question Which CRI folks would have to answer do they want to have a different version? How do they want to structure this protocol when the feature parity starts being very very different in various Brails, I'm not very familiar with that, but I'm pretty much sure we will see something what what's happening with Kubernetes like we would have V1 alpha, which is a very very basic version V1 beta where we would be able to enable maybe additional features and so on It's all up in the air. I'm not very familiar with that But a lot of interesting things are happening in the container run time now Now speaking of which for instance Fedora now defaults to container on time called CRUN, which is a C based version of the run C. Let's call it like that The benefit is that it's much faster instead of 10s of Hundreds of milliseconds, which it takes two containers to run We would have tens of milliseconds like 50 or 70 There is also a Rust based container on time called Yo-Key Which has similar features and performance rates so in Okiti, thanks to CRI or interface, we would be able to swap them or Either by default or you would be able to define a runtime class where you would say I want these are the workloads I want to run super super fast So these are the workloads which should be used in CRUN or Yo-Key or whatever else you want So all these new features happening that CRI are very very exciting and While they don't give you additional features you can make use of but the performance should be much much better than we previously used to That's really cool. I mean it's really fascinating to see like what's happening with all these different kind of like container run times And I mean I didn't I know there's a lot of work going on with Rust So it's really cool to hear about like Rust runtime and everything so really interesting look into the community Yes, there is also Cata containers I'm not entirely sure if we already have the operator from them in the community catalog But if not, that's definitely something we'll be looking on that one It's more focused on security and the virtual machines instead of plain container run times But all of these features are very very exciting to us kind of low-level engineers They probably are very interesting for people who want to deploy bots, but For us, it's really really fun stuff. I feel it like in general We've made great progress in terms of maturity over the last year So open chip feels much much more mature and we've been able to kind of split out a few parts from the core Into optional operators and that is really great for us too because we have to maintain less for just the core functionality While the operators we can now use for delivering any additional Stuff like Cata containers support and although that might actually have to be in the base I'm not sure about that but other things like Windows container support Things like that or Windows nodes support on the cluster those can now be added as an operator to the To at the okd deployment, which I think is just marvelous. I really like it And yeah for us, it's great because we have to shit less in the core payload when we can can split things like logging out of it and I do hope that we will and I think we will continue down that further and reduce the Minimum viable needed payload even more Reduce the footprint for that thereby and still enable all the use cases by just adding adding them Back as as optional operators from operator And we've actually maybe as a kind of preview We are now very actively working on getting an okd specific operator catalog up So we can really deliver those operators that have kind of been missing in okd so far or were difficult to get To make them the first first class citizen and make installation of all those operators Super easy, which we hope will will obviously lead to more Yeah, more participation and especially people just Using their okd classes in a productive way for the pipelines operator is a good example That's the one based on tecton and there is multiple operators that we wish to ship in it in that catalog. So it's gonna be very easy to actually solve Right now you'd have to build them yourself in some in some cases If you're not if you don't have a subscription obviously if you if you install it up Okay, you can be open ship subscription. You can install all the open ship operators on top of okd as well Without the subscription you'll need to So, yeah, I know I know that's a topic that's really you know popular in the community You know, we we were talking kind of the low-level stuff now We're talking kind of the high-level stuff the operators and whatnot I guess like and this is a question that I see come up frequently around the community is like, you know Red Hat has its operator catalog for, you know, kind of the open ship container platform and okd You know, there's the open source kind of operator hub dot IO And I know Christian you were just talking a little bit about, you know, the community having interest in in kind of like Making this better I wonder if we could if we could talk a little more about like, you know, what the community might be trying to do You know to to make this more achievable Yeah, so we are thinking I'm sorry about my audience That I have bad incoming audio is probably the same on the outgoing side So what we're actually going to do is we'll set up a sub working group focused on the operator And on operators so people that either have their own operator they wish to specifically released to okd Or people who use a lot of the optional operators so they have a platform to at forum to Discuss all the things specific to that That is also so we on the core side I can kind of focus on that more and we have a dedicated forum for the operators And I think that will be a great Yeah, just just a great group To join if you're interested in in one of those optional operators specifically The use case is called that I know Diane who isn't here today She's also very interested obviously always in hearing what the community does with with okd and with these operators because she's not only The community director for okd Also, I think for the operator So she's gonna be Interested in all of these use cases and if there's folks in the community who are already using Or in the future So I'm gonna try to summarize a little bit because your audio got a little got a little difficult there But so it it sounds like in summary though The working group is gonna is gonna create a subgroup that's going to look directly at kind of like operator hub And how we can make it easier for the community to get involved in these things and they're also gonna help to act as a liaison to Make those interactions a little easier for people. Is that is that kind of the general just the things? Cool So just checking the poll again We're now up to six yeses for using okd and we've we've gained our first v-sphere vote and one more bare metal vote as well Sounds good Christian, yep Well, I mean actually it sounds terrible, but like the idea sounds great So I'll kind of ask an open-ended question here What what are you looking forward to? For the future of okd in like, you know as over the next couple years like as we move towards Openshift 5.0 or whatever in some nebulous future. What what are your kind of high points? What would you like to see okd achieve or what would you like to see happen in the community? Oh? Wow I'm definitely interested in Participation in a lot of things we started adding fancy new components like metal be and Other network things I don't quite understand how they work, but I'm pretty sure communities very excited about them We definitely want to get them used like experimented with them and which features are lacking which are more interesting than the others and Let it be a gateway for the people to participate in upstream We kind of have already did this with the long-standing That was an example of why we're running for the Fedora 34 right now. We are blocked by Fedora change in Selenix that triggered bug Rather the change was We were not allowed to revert it because it makes sense. It was Stricting the handling of TMP files, but Kubernetes tests were relying on that feature to pass a critical conformance test as a result Mustafa who was a new hire for us had to dive in into the whole world and his mission was not just fix it in the In the okiti With the one this just starts to be skipped or passing for us. We want the whole issue to be resolved by fixed in Kubernetes then It caught cherry picked into previous version which were more interested in Then the okiti was every based on some of Kubernetes and then finally our tests were based on that version of Kubernetes So it took quite a while But the whole issue is now just to eradicate it entirely. It's not just patched and hacked this is probably What I would be very very interested for people to see that means they would commit to Okiti and the whole Kubernetes idea for quite a long time because they would have to invest quite a lot of effort to get this done It's not just patching one line of code. It's Communicating with a bunch of people but in the end you get the result and everybody benefits from it and You Understand how the whole communities work while you're not even paid to get this done But this is the the actual right way how we are envisioning the community. So supposed to work. So if not if People would be using the fix in Kubernetes bugs once they encounter them in okiti Then our mission is one of the goals is definitely completed We have introduced people for the communities and They benefit from the and they reap the what the community is so When it comes to technical features I don't even know I can even dream what's gonna happen in five years because Previously the things like the whole idea of a system installer was was crazy to me I couldn't imagine that you can just click next next next through and you get a cluster I'm thinking a more focused on security would be The key there kind of containers is definitely a huge feature which people would use I'm not quite familiar with what's happening with operators But I'm definitely sure that operator hubs would be growing both in quality and in quantity of our containers they're getting For instance, I remember there is a open shift commands meeting focused on databases specifically in Kubernetes I'm thinking the more and more these kind of events would be happening like focus on pipelines on Logging and maybe who knows so this kind of a qualitative growth is Definitely what what would like to see I Think I mean, I think that's that sounds really exciting like from the community perspective It's it's tremendously exciting to hear about kind of the investment in making this a pathway for people to be able to Contribute all the way upstream whether it's, you know, Fedora or Kubernetes or the Linux kernel or whatever And yeah, then you know kind of on the on the workload user side of it Like that's really cool as well kind of reaching out and making it a much better platform to run on So it sounds very exciting to me So what what do people in the chat think anybody in the chat got questions or comments or you got you got Vadim here I'll limed up ready to answer some questions. So so dig deep Yeah, so Stewart says definitely excited to have more operators on the okd operator hub That that is that is a request that we see very commonly from the community, right? The whole thing with the okd catalog of operators is that We don't want them just to be built there and lot rot we want the redhead teams To participate to benefit from user reports from experiments and things how they envision this whole thing working This is why it's taking quite a long time because we have a lot of parties to to be satisfied We have some early adopters who want to jump the ship right now, but We still need to align quite a lot of parties because we don't want to mess it up when we launch it Other than that. Yeah, I mean the whole the writers idea is apparently sticking which is greater here That means people can communicate via the community version of the operator hub and okay the users would automatically get it Um, I'm also quite excited what people would love to to build with operators for instance of the whole matrix synops Setup which requires Postgres ready it ready already Python application and some more workers is a great fit for the operators because the workers are expected to be scalable and Other than that, it's a pretty standard operation. So That's a great target for things. This is where I'm thinking We would this is what I would love to see more like the end user applications through which they can run right now Even if it's a basic operator, but nevertheless, it's incredibly useful because From what I'm seeing a lot of people Build a cluster in which stands there waiting while they could make use of it running some useful and level of locations and during the summer's Short okd summit if I can call it like that The home lab session was filled with people who are running quite a lot of interesting Applications for their own personally used. They don't care about HAA. I don't care about that They are young manifests or are muddy But they make use of it and that's the whole point of the okd Kind of in that same area for me would be something like a next cloud operator. There is already a next out helm chart That is easy to deploy But automating that with the operator SDK because it has that capability obviously to automate helm Chart deployments or even making it a proper go Operator would yeah, would just be awesome. And I think yeah having those operators in their matrix next cloud That will be interesting not just for cell phones, but also for Just smaller smaller companies that want to run their own services Things like that are smaller institutions. It doesn't have to be company could be small school That uses next cloud and and matrix for that chat app or a university over every So yeah, I do like that we that we have made it easier to create those operators And that we're still continuing down that path because I think that that pattern of operators that just might manage themselves on Autopilot as I like to say It's just amazing So Christian we got here because I had asked Vadim this question while you Were fixing your technical issues there and I guess I'll pose the same question to you Just to see maybe where you're at on this But I would I had asked Vadim, you know kind of over the next year two years three years You know, what are you looking forward to most in okd? Like, you know, what what are your kind of visions or things that you would love to see, you know Happening or occurring over the next couple years So with my okd user hat on I would really like Further reduction of the footprint make it possible to Run okd on maybe not the current Raspberry Pi 4, but definitely on the Raspberry Pi 5 Something which hopefully will come Well, not this year, but probably next definitely on the smaller footprint on arm Just more efficiently using less power With less power consumption That would be super interesting for me. There's also I think where it's not really ha, but it's kind of ha It's like a an AB deployment of two single node Open shift Deployments, which would kind of fall over to the other one I think that would be amazing if you have like a machine that is big enough But you still want that it well it is ha in that case just isn't Isn't a real kubernetes ha it's just two to single notes that would be interesting So you could kind of do do something like a day with just two machines and still get the full The full ability of of your full okd cluster the capability of that Yeah, and I think those edge use cases are gonna be super interesting I mean deploying an okd cluster at home is by definition an edge deployment So, yeah, I think That's gonna be that's gonna be interesting and obviously we are working on that further to to minimize the core And reduce the footprint there without compromising obviously on functionality. You can always add those operators back Through operator help. Yeah, so I'm excited. It's gonna be it's gonna be just better from here on. Yeah Yeah, I think that's I think that's a really interesting answer about the smaller put footprint and everything because we do see a lot of requests You know people curious about single node deployments and how they could maybe set up a development You know system where they could try out open shift. I wonder, you know, I know inside red hat There's a lot of a lot of work on creating single node type architectures But I'm curious if maybe you could talk about how that how that's happening in the community single node clusters are very very like get a large share for for our user base that's for sure the problem with them is they are mostly used for development and People want don't want 90% of the features that I'll give you provides like if you're running a single out, you probably don't even need SDM and and And probably you don't even need an image registry as well. You can just use quay and Things like that like monitoring and stuff like that. The thing is We are pretty large scope projects Which is falling into the category of what? CRC and what micro shift are doing we're kind of overlapping and While it would definitely be great to use less memory and things like that But maybe there is a better tool for this whole job like there is a micro shift specifically designed to run on the single board computers it has the flannel instead of OVN choose much less it has some components removed Which you probably won't need because you don't build stuff And store them on the image registry on the edge. You just get deployed images directly and There is a CRC specifically designed to be created turned down just for quick Development uses and this are there are areas where we overlap and probably these are not the areas where we're supposed to be expanding and maybe there is a better way of more Fully community driven open source system, which is not covered by CRC and a micro shift So while it's not really great to have less resource consumptions, there are still better tools for the for the task It's really great to see a lot of innovation happening in those different areas because that lifts up quite a huge Mountain from our shoulders where we don't have to rip out quite a lot of things to make go kitty run on on Raspberry Pi there is a micro shift for that Well, what's the relationship with micro shift actually doesn't that use okd under the hood? pieces of the It uses images it uses fedora IOC, which is effectively Fedora cross but specifically for arm and With a slightly different focus, so we share a lot of things like Fedora packages images for base, but yet they're still entirely separate entity and They have make their own choices. We have may make our own choices It's great that we can share quite a lot of they don't have to reinvent stuff from the beginning but We definitely should should be in touch in contact with them though Inviting them on to a board group meetings would be lovely, but yet we have to be aware that maybe Some use cases a better handle the micro shift when okd. You should just not spend quite a lot of time fixing them That hasn't been on my radar too much. I had heard about it, but I wasn't really sure What what they do and how they do things that sounds more like I should probably be Deploying micro shift here at home But Well, I think yeah, I will I will send out an invitation to those to that team So they can maybe just you know come join and Present what they're doing there to us here at the working group. So we just build awareness of each other Yeah, I think obviously that they'll there will be some separation of concerns Which some things are not they're going to be handled by micro shift and others by okd But it would be good to to just be aware of what the other side is doing So I will invite them to one of our next meetings And just as a heads up here, we're just about at a little about five minutes left in this session So, you know for people in chat if you've got a burning question You need to get out or something you need to say to Christian over DM like now's your chance Well, I hope this session was entertaining and informational infotainment you might call it To everybody here and I think Yeah, we're almost at time. There's no questions. I'm just my my audio lag is starting again. I don't know what this is Well time to flush the buffers again, right? Yeah, well Big thank you to Vadim and Christian for joining us today and and for answering questions and for sharing this You know the vision of okd and kind of what's going on So yeah, thank you Thanks for having us Thanks Mike