 Okay, hello everyone. This is the RDO Meetup, and I'm going to hand it right over to Amy Marich. I hope I said that correctly. Close enough. I have a southern accent, so I pronounce it Marich. My brother does not have a southern accent. He pronounces it like you, so you can't be wrong. So, this was originally supposed to be in person with everybody, so it's really informal, because the idea was to actually meet with people, talk with people, and in Burno. So, we're here to talk about RDO. Amy, would you like to invite others to join you to talk as well, or do you want to just run through some slides? Well, let's run through the slides, but if anyone wants to ask a question, they can go ahead and join up. I have mentioned this Meetup to our community, who's mainly in AMIA, so we may see members of the community join in. But, like, Rich can always talk about RDO, so can David. So, anyone who wants to join in, please feel free. Excellent. We'll see if this actually works. Here we go. So, I wanted to start off, actually, with what is OpenStack, because RDO is part of OpenStack's community. So, OpenStack is infrastructure as a service that utilizes a common API. So, basically, all the services use the same basic API. Of course, it is different between the different services, but you can send the same commands. And authentication is through Keystone. Everything controls large pools of compute, storage, networking, and you can be in one or more data centers. Now, more recently, we've added the ability to control your infrastructure with Kubernetes, Cloud Foundry, as well as our OpenStack SDK, which is our CLI in Horizon, which is our dashboard. And you can do bare metal virtual machines, containers, all within your OpenStack infrastructure. So, there's various projects within OpenStack. And this is a little bit of what this slide is showing you. So, on the front end, you have Horizon, but we also have, like, EC2 API. So, you can talk to EC2 and use the same scripts and language between the two, especially if you're using heat. There's workload provisioning, Magnum and Trove are big ones. Application lifestyles, Solom, which is a little older, Masakari. Orchestration heat, as I mentioned, but Mistral and Sendlin are other good ones. Compute, everyone knows Compute, and that's mainly Nova. But if you're working with containers, that's Zoom. For storage, there's three types of storage. Swift, Cinder, Manila, Manila is shared file. Swift is object and Cinder's block. And some of the advantages of you can use stuff as a back end for these, if you want, as well. Networking, most commonly known as Neutron. Octavia is load balancing designate, which is getting a revitalization as DNS. Hardware, as I've mentioned, is very important. We have the Ironic project, and if you're using accelerators, there's Cyborg. I mentioned Keystone a little earlier. It's a shared service for identity placement, which is scheduling. Glance, which is where your images are going to come from. If you're doing secrets and more secure stuff, we have Barbican. And there's a couple of different projects for lifestyle maintenance. OpenStack Ansible, Triple O, Cola Ansible. So there's different projects. You can choose Bifrost, which is a bare metal. And then where we get involved with RDO is the packaging, which is RPMs in our case. This one is different. So what is RDO? So RDO is a community of people using and deploying OpenStack on CentOS, CentOS Stream, Fedora, and Red Hat Enterprise Linux. The community itself was launched in 2013 by Red Hat, and Rich was, I believe, the first community manager architect for the community. So thank you for all your hard work, Rich. And RDO is available for free and is based on the OpenStack releases. So after OpenStack makes a release, most recently was Xena. A couple of weeks later, we come out with the RDO release because we have to wait for everything to come up. Oh, Dave Neri was the first person. I'll have to thank him. So RDO is involved in various different efforts. PacStack is the most common one. It is the CentOS Red Hat Enterprise Linux version of what we'd use for upstream, which is PacStack, I mean DevStack. So here we have an effort that we create for all-in-one proof of concept. Triple O, which is the upstream deployment project. Dave has it already with PacStack. Yeah, and PacStack used to be the methodology for deploying on the CentOS and rail type environments. It's real easy to use. So it's really easy to use and it is easy to grow out. Triple O is an interesting project because it's OpenStack on OpenStack and it gives you a lot of flexibility and a lot of configurability, more so than PacStack did. So basically you have an undercloud, which is OpenStack, which then deploys your overcloud, which is OpenStack. Now, as I mentioned before, RDO is very involved in the RPMs for deployment. And we do that really also as part of the CentOS Cloud SIG. So RDO represents RDO as well as OpenStack into the SIG to promote the use of CentOS for cloud infrastructure. So how to get involved in RDO? We have mailing lists, which you can find at RDOproject.org. And we have a users list as well as a dev list. IRC with the implosion of FreeNode, we have moved as well as OpenStack to OFTC. And you can find us in the RDO room. We are also on Element, which is tied into the OFTC room. Meetings where every Wednesday at 1400 UTC in RDO. True, it is Matrix Night Element. That's where I use it. And I want to just leave this up here while we talk. So if anyone wants to know how to reach us, that is up there. I like Element because it's web-based and I can just connect to everything. I am really bad since FreeNode died. I do not have my bouncer backup in running. So Matrix is great in that you do not need a bouncer. So like I said, this was really supposed to be just a gathering to talk and meet people. So does anyone have any questions about RDO, OpenStack, how to get involved? And if you would like to join us on screen, just let Michael know. So I guess while we are harvesting some questions here, I might ask a question. So I had been involved in the OpenStack community when I joined Red Hat and I was working on the Sahara project, which is kind of a workloads type project. And I am curious as time has progressed, back in those days, this was probably three or four years ago, there was a lot of effort around writing workloads for OpenStack, writing an OpenStack application or something. And I am curious, do we still see that trend today? What are the workloads that users want to run directly on OpenStack these days? So a lot of it is going towards running your Kubernetes on top of OpenStack. Within Red Hat we have what we call Shift on Stack, which is OpenShift on OpenStack, but that is where Magnum comes in and Zoom. So if you want to be containerized on top of your OpenStack cluster, you can. And then on the infrastructure side, there is also more of deploying to containers. For a while it was all, you deployed on bear, not as bare metal itself, but you deployed directly on your machines. And then we have gone to containerization because it makes upgrades a little easier because then you just upgrade a container and put a new container out there when you are doing your deployment. And then in the last few years deploying bare metal as part of your OpenStack infrastructure has really, really grown as people go back to basically using hardware. So you are able, with Ironic for example, to deploy a new system as a bare metal machine versus having to use VMs for everything. So I think that has been really important in LLVM's network storage on top of what I can do whatever I want in my container. So what David is saying in the chat is I'm a bit old school and like OpenStack provide vanilla VMs network storage on top of which I can do whatever I want easily containers, k8s, applications, etc. And that's how I actually build it out too. I can sometimes joke that I can do a RPM install faster than I can use some of the deployment tools even though I'm involved with the deployment projects. Just because I've now done it so often that I like to like configure it the way I want to. But the deployment projects from when I first started in OpenStack with Grizzly have made deploying your OpenStack infrastructure so much easier because you don't have to touch every machine and you can configure your networking any way you need to. So to kind of bring it back I guess it sounds like the real popular workloads today is really just to use OpenStack almost as like the data center software that it kind of originated as where you can just kind of like get VMs, get networks, get storage and then a layer whatever I want to on top of it myself. People aren't necessarily trying to write OpenStack applications per se. He is still popular for that. So you have your stacks which will deploy your database for you, your web servers and so on and so forth. But OpenStack ultimately has always been infrastructure as a service. And that's where its strengths are. Yeah, and I think during the era that I'm talking about when like the Sahara project was very popular at that time, you know there was this notion that people almost like you know as Kubernetes was becoming popular there was this notion that you might write an app for OpenStack kind of in the same way that we see people writing apps for Kubernetes today like writing an operator or a controller or something. So I think that this to me was always kind of an interesting trend in the community. Yeah, and there still are things on the marketplace that are basically applications you can install on top of OpenStack. But OpenStack has really become popular in for your open public clouds. Vex hosts OVH, City Network and they're rock solid. And they can compete with your AWS's and your Google Clouds as far as you know having good infrastructure for you to deploy what you want on top. And then of course we're always popular for private clouds because you can run your own cloud within your own data center. Telcos and Edge are very, very big into OpenStack because they can deploy what they need in their main data center and then just have a small node out in wherever they need them, whether it's Edge for Telco or whether it's for like onsite sales, you can do that with Edge. So I don't think we're concentrating so much as a community on what you're deploying on OpenStack but making sure you can deploy whatever you want on OpenStack. That makes a lot of sense to me and certainly from my perspective and I do a lot of work on Kubernetes and OpenShift and specifically on our cloud infrastructure layer. In the upstream communities that I'm in like OpenStack seems to sit right alongside AWS, GCP, all these other clouds in terms of how they integrate with the projects and kind of like their presence in the upstream. So I think it's really encouraging to see that. Yeah and that was one of the thing with the EC2 API is that you can use the same thing within OpenStack or within AWS. And I think that's the most important thing when you're talking about an open source project is that it can be used in other locations that you can share that you know what you use on OpenStack you can use on Google Cloud and so on. And that's kind of where Kubernetes went as well because Kubernetes came in as no container deployment and you should be able to run those same containers anywhere that you need to. So then you get into the whole hybrid cloud model and from the OpenStack side of things our hybrid cloud was more originally the thought of public versus private because that's where we were at the time. And then you know all the other cloud providers came out and you know then it does become can your stuff run on us as well as everybody else. Yeah makes sense. And thank you for indulging me. So who else has got some questions or would like to join the conversation here. David's doing lots of typing in the chat. Yeah I'm kind of curious what David's got going on in his basement because it sounds like an amazing OpenStack cloud built there. Yeah when I first met David was actually as part of OpenStack Ansible because of the Ansible key and that particular project. And then he came out with ARRA so which has been very important to the Zool testing environments that we use in OpenStack. So that's another thing to take note of is the fact that other projects have spun out of OpenStack such as Zool which is our testing environment which if you haven't used it is great because what it allows us to do is test within the project itself to make sure that any patches work. But then we test within the whole everybody's patches that are merged up to that point. So if you get through the Zool gates you should be bug free. I say bug free but occasionally you know something got through that wasn't being tested for and I think that exists in any gating or testing environment because if you didn't add a test of course it can't test for it. You know I think that that's a great call out like Zool is such an amazing piece of software and you know I mean I you know my experience with it is as a developer and I think probably you know most OpenStack users you know may not even know that it exists. But yeah it really is tremendous work that the community did to build such a thorough testing platform that could integrate you know separate projects to really like test this matrix of compatibility. So yeah I'm always amazed when I when I kind of look at that stuff. Yeah and one thing we've done within RDO is originally some of the contributions for RDO like the website were through GitHub. But because you know we want all OpenStack contributors you know even RDO contributors to be able to contribute upstream if they want we moved over to using our own Garrett for even the website so that if you onboard for RDO and you learn how to use the systems and make patches and everything else. You can then contribute to OpenStack itself because you're used to the tools and I think that's important that you shouldn't like use one set of tools for one thing and another set of tools for other things because then you've got another learning curve to contribute. So that was one thing I did early on within joining the RDO community and also the very fact that if you're doing translations if you're doing documentation if you're running meetings. Your contribution should count as a contributor and by having all the tools so that when you are an RDO contributor you are an RDO contributor and you contributed docs you contributed this or that. And we've also started you know like some of the other projects we have contributor swag you know after release so if you did something during the release cycle you know we give you something as a thank you. I think I think that's a tremendous move towards inclusion as well just to say you know what we're just going to say you're an RDO contributor because you know it's a team effort right. Yeah and it wasn't that anyone was being necessarily excluded but going back more to the four opens of OpenStack itself and how we can include everyone and everyone's contribution is important. Now going back to something you were just saying about Zool and RDO and whatnot and I just I'm just curious is that that testing work is that what's happening around the software factory project? Yeah so we have software factory which allows you to use your GitHub ID and that's where our Garret resides our bug tracking and things related to patches. We are using Zool upstream which so everything gets tested there and then we bring it downstream and we test it again as we bring build our RPMs and things. Yeah really really cool work going on over there. David said he asked you about it. Sorry David I missed that. And I think another thing that's important to note is RDO is leading the efforts for the use of stream upstream. So CentOS 8 stream was the first changeover we made from CentOS into stream we're finalizing the move over from 8 stream to 9 stream currently. Hi David. Hello I didn't expect to be here but I was in the previous session which was for the Ansible community and now switch over to RDO and like oh I'll stay I know RDO I've been there. So I was once upon a time I was part of the team that released RDO. I still love RDO and contribute from time to time but it's no longer my full-time job. And yeah I was talking about my lab environment here in my basement. It's a very I say it's a cloud but it's a single node in fact. I used to have much more than that but to be honest even in the basement a couple of servers it doesn't take long that it's super noisy it consumes a lot of power and the heat. Let me tell you about the heat. You know in the winter it's great I don't need to warm up my house but like in the summer it like I needed a dedicated air conditioning just for my office. So you know once you get to a certain point I console so console dated a little bit and now everything is on a single 2U server. It's a you know by all means it's not a small node but I use it to host all of my stuff media center lab environment you know for Kubernetes OpenShift and simple stuff. So it's really useful because then I don't need like a cloud account you know a cloud provider I can just do it you know from home and I can continue learning stuff. And it's it's the play with PaxTac because well you know PaxTac under the hood uses Puppet and you know even though I'm an insible person nowadays I don't mind my Puppet is rusty now. But hey it works and I know it's a very important project to RDO it's part of the testing pipeline and all that. So I know that you know whenever I try it it should it should work right. So not that I have anything against TripleO but like I don't I don't need all the bells and whistles right. I just give me give me compute give me storage give me network and I will take care of the rest. And TripleO does now have an all-in-one that installs fairly quickly and gives you everything you need as well. So that was a great addition to TripleO because I'm a big fan of the all-in-ones like David we used to have two servers in the house. Now I run a nook and we have a couple raspberry pies to do what we want because yeah it's a lot of noise to run the servers. You know so having the all-in-ones is great because not only can you run what you need as David said but it's a great way to learn how to use OpenStack. Because you have everything you need you have your compute your networking you know storage whatever and with pack stack as well as dev stack. You can also add in other projects. So say you did want Sahara installed you couldn't you can tell it to install that but you generally you have you know your five main ones. Nova, Neutron, Glance, Cinder and Horizon and Keystone actually so six you know and you can learn how to use OpenStack without needing a whole lot of infrastructure. And I think that's really important you know because the more hands-on you get with something the better you are. You know and then it gets to the point where oh yeah you want a networking thing you're you know and you're doing it in like two seconds and you can then explain to someone who's never experienced it. You know how to do it because the most important thing you can ever do in operations is get your hands on things. Yeah that's that's so right I mean I've learned so much over my career just doing OpenStack because well OpenStack what it does it provides APIs you know and abstraction layers on top of pretty complex technologies. You know virtualization networking like I'll get me started with networking it's so complicated. But like when things go wrong you need to you know dig in and understand what's going on under the hood and you know by way of working with OpenStack you get to learn a little bit about everything and you know it's great I learned so much about it. And you can say what you want about GUIs but I love the topology for neutron. You know especially if you're trying to explain someone how the different pieces connect to visually be able to see that I think is great and he does the same thing with your stack it gives you a very good visual representation of your infrastructure. So whether it's just you trying to understand it because something broke or just understand it as far as how the different pieces connect there's so much value in the visual of things. Sure some things you can do really quickly on the command line you know but being able to switch to do it in the dashboard I think is very valuable. So knowing how it all connects on the command line to say bring up your network your router and your switches is one thing but being able to see it visually and also you know do it within the dashboard can give you such a visual learning. Because not everyone is textual based learning visual learning is very important and sometimes we forget that because we all talk to CLI because you're a real operator if you can just use the CLI. There goes my camera sorry about that. Yeah there's a little bit for everyone right like sometimes I use the CLI sometimes I use the the horizon interface you know you cannot you cannot expect everyone to go through the CLI or expect everyone to go through the dashboard so having these options is great. Yeah and there's a new project skyline that is coming out soon. They still have some more stuff to do but they've been merged into the open stack namespace which is going to be a dashboard equivalent or alternative I should say to horizon. So whereas horizon is Django skylines using more up to date technology because you know when you've got something like horizon which has been around for so long. You would have to do a complete rewrite to get it up to speed and it's really interesting to note that the two different project communities are talking to each other and working with each other to make sure everything we need is there. And whether horizon keeps going because so many people are using I suspect it will but some newer people may choose to install skyline. It's not quite ready yet but it should be within the year I would say. It's really interesting to hear about skyline because yeah I know that when you're building a web app you know especially a front end back end app that's as complicated as horizon is you know there are choices you have to make right and and those. It's not necessarily good or bad you just did these are the tools that you build with and you're absolutely right you know horizon for as solid as it is has made choices about how they decided to develop you know with the technologies. And naturally there have been other development paths and people have been asking I think for years you know what could we use these you know programs or these frameworks to build a web app. You know and like you're saying it just wouldn't be possible to refactor horizon to match something like you know like a react front end or something like that and so it's really interesting you know to me and encouraging to hear about like a parallel project developing and kind of like the community rallying around these things. Yeah and the interesting thing about horizon that maybe a lot of people don't understand is a base horizon only has those base projects of compute network he's done and so on. And then all the other work is done with to some degree within the project themselves. So if you want the magnum UI you have to tell it to install the magnum UI. So one of the things is why I say Skylines probably a year out is because all that modularness will need to be replicated at least for the major ones. Trying to think of what other new and interesting things we have going on. For those that don't know Open Infra Summit will be in June in Berlin. Open Infrastructure Foundation has said it will be live no matter what but we may move location and time if we need to if we can't have enough people in Germany or Germany says no one from outside that the area is allowed in. The call for papers is currently open. It closes on February 9th. And let me I will get the URL and paste up it's basically CFP.OpenDev.org. Rich, they have not announced any proposed locations. I know Vancouver was one of the ones that we were canceled so contractually that's a good possibility is Vancouver. But we have not gotten any hints of where it might be because they are we are going to be in Berlin and that is the hope but then Omicron came out so that gave us some doubts. But the hope is Berlin in June. There will be an ops meetup the Friday and possibly Saturday after which is a great opportunity for operators to come together and talk about OpenStack their deployments. Seth is usually a popular discussion during that meetup as well. So we're planning like Berlin is on. And we will know in April if we're not going to be in Berlin. I think that's the cutoff date for if we need to move it. But my gut says if it's not Berlin, Vancouver is the backup. But that's just me. I haven't traveled in so long. These virtual conferences are great but the burnout is real and I can't wait to see the community once again. Yeah, I was lucky enough to get to open source summit which was moved from Dublin to Seattle. That was really bummed about not going to Dublin and Kubecon which was in LA and it was great seeing people again. But a lot of people and a lot of companies you know weren't ready to get out there and chose not to go to the events. So where fingers crossed for Berlin and I think that's the safest way to say it is fingers crossed. And that's one other thing that's affecting a lot of the call for papers is you've got the one group of people who can't wait to talk in person but are scared to apply for a CFP because it may go virtual and they're burnt out. And then the other half is people who are not quite ready to travel because of all the concerns. So they don't want to put in a proposal with the thought that they may have to talk in person. So hopefully we're going to have a really great set of proposals for Berlin but it's still open until the 9th. I'm going to put in at least one talk possibly to myself plus having a diversity networking lunch and other things we'll have going there that I'll be involved in. I have to drop but it was nice talking to you and keep RDO going. I like it very much. Thank you for all your work on it. And thanks for coming on. So I guess as it's a little slow I guess in the chat I'll ask another question here. And maybe this is a little bit too much of me wearing my red hat or whatever. But RDO is like a really cool project. I've always thought the community around it was really interesting. And we also have the OKD project which is another kind of red hat I guess led community around open source. And you know we know OpenShift runs on we know Kubernetes runs on RDO. I'm curious like do we ever are there ever any events or crossovers between the RDO community and the OKD community? There haven't been. That is a good idea. So like I mentioned the ops meetup often has a very heavy sep component to it because a lot of open stacks use sep for their storage. So we're trying to encourage more of that. But I like that idea of you know combining with OKD and maybe getting involved you know having some open stack talks within Commons. Because I'm sure there's people who are doing it. Yeah definitely there are some open stackers I think in the community. I mean really I go to a lot of the OKD community meetups and you know there's a lot of talk there about vSphere and vCenter are very popular platforms to deploy on. You know because these are the kind of things where it's like I could deploy it on some machines in my lab or whatever. And I think given the talk today about you know how good things have gotten in the open stack world for doing like a single node installation or doing a small installation. You know that might be really attractive to the OKD community who also likes to play with open source. And you know I shouldn't say play but you know some of these people are doing real enterprise work with this stuff. You know and it's like it might be really kind of peanut butter meets chocolate kind of moment right. Yeah and one thing that came out of the open infrastructure keynotes that were held in October. Maybe November was the term low key not low key the project but low key as a concept of Linux open stack Kubernetes infrastructure. So it's the same term as a project itself. But yeah because that's what a lot of people are doing they're running Linux as their operating system and then open stack and combining it with Kubernetes to make their infrastructure. So that is really actually a good idea and I'll reach out to Diane on that. Because we are so while upstream is pushing it you know we're kind of pushing it as well now because that's where people are going. Right and I think you know from my perspective the really interesting thing is that like installing Kubernetes just using the Kubernetes tools like Kube ADM and similar. It's not a it's not a terrible experience you know you can get Kubernetes installed but it does become rough around the edges and they're you know networking in specific and storage or you know they're difficult to configure sometimes. But if you're able to install open stack you know the installation for Kubernetes on top of that or even OKD on top of that is very automated for you because it you know it acts just like an infrastructure provider as opposed to an individual machine or a collection of bare money. Metal machines so for me it's like yeah if it's easy to install open stack and then I could turn around and install Kubernetes or OKD you know using a quick installer like that's like the ultimate in kind of like user bonus I guess. Now I'm going to turn on my nook before I get my new desk and try this. Awesome I love it. I like this idea. Well interesting. This is what I have done internally on some of our machines is I've used machines in our laboratory to install a single node open stack and I wasn't using RDO I was using the productized you know open stack the redhead cells. And then yeah I use the open shift installer on top of that and it all you know it all seemed to work kind of auto magically for me so. You know at least with I was using the commercial versions but I've done OKD installations as well not on open stack but I don't I don't imagine it would be any different so for me it was a great experience to kind of like go all the way down the stack. Yeah and I know there's instructions for installing service telemetry framework on top of OKD. So that yeah this would actually be a good thing because if I can get it running it's a good blog post or instructions for the OKD documentation. Because personally I've used mainly Magnum and zoom for my Kubernetes on open stack. It makes a lot of sense right. Magnum does take a lot of horsepower which is why when I just want a single you know container running all you zoom it's a lot more lightweight. But because don't forget I'm using a proof of concept machine which is usually a VM running within a VM. Right right and you know I had the luxury of having access to like a 40 core half a terabyte of RAM you know server instance so you know it's a little bit different than even that setup or David's you know basement laboratory. Yeah I went to bring up the old Dell machine or the old sun machine here at the house and it's like it's too old to run any drivers. Which is why I went and got the knock. Yeah so David says yeah I reach out to Amelia. And Amelia for anyone who doesn't know used to be the PTL for triple O. So. And he helped me get my open my open shift installations working on open stack is he's really great with this stuff. And that's one thing that's really important about community. I don't think anyone's really really gotten into it from the meetups I've been a day is asking for help within the communities. Because it helps them know what your issues are as much as it helps you figure out your problem. Now it's not paid support though you know whoever wants to pick it up will pick it up and you may not get a response right away. But if it's really interesting you'll be surprised how many people jump on you know a real issue because they're curious and they want to solve it as much as you do. I think that's absolutely correct I mean I you know for transparency sake I work in engineering at Red Hat and I've been an engineer for a couple years now. And yeah like especially with open source projects being able to get feedback from the users about what they want what they like what they don't like. You know it's it's really important to get that message back to the people you know who are oftentimes maintaining the software. And yeah like from what I've seen developers usually eat that kind of information up because it gives them a really solid way to understand what should we be building what should we be focusing on. Where are the problem areas you know so yeah I think you're absolutely right. Yeah especially if it's like an edge case use case you know no one thought about that I mean and a lot of the times because no one thought about those are the things we're not testing for. Right so if we don't need users having a problem then you know we don't know it's a problem right. Or if you don't know someone's trying to use your software in a certain way you can't test for it because you didn't think of it. Right yeah exactly. So yeah that's where the importance of you know operators being part of your community comes in. Being on the mailing lists even if you never send an email to a mailing list like I keep everything I can go back years you know and the ability to search. A error message that someone else did or someone just saying hey you know I did this this way and it worked out really well is such an added benefit. And yeah there are the archives you know for all the mailing lists that use Mailman RDO included OpenStack as well. But having everything local you know to me is just quicker and fun so I'm a pack rat. As I watch the unread count on my OpenStack dev mailing list I go up and up and up. I look at them and at least breeze through you know because then if two months later I see somebody asks something and I'll go hey wait someone asks something very similar and then I go look for it. Because I think that's important is having an idea of what's going on so that you know you can you may be the only one who like catches those two things. So sometimes the important part of being in a community is just being able to put the right two people together. Yeah exactly exactly. And you know speaking of community this is something that's always impressed me about the OpenStack community in general and I guess now the open in for community is that you know the sense of effort put into building the community and making sure there are good experiences for newcomers to the community. And you know things like mentorship programs and internships and what not like I've always been tremendously impressed with the way the OpenStack community tried to build things in a way that included people and made it easy for people to kind of work on these things. So like I always look back at just what a great experience that community is. Yeah they really do believe in the four opens which is open community open development open source. And of course our open governance as well it's you know what's going on you have the ability to know what's going on and I think that's important to know where things are going and to be able to follow along. You know everyone is like you're still on IRC but yet anyone can join and we log everything. So even if you don't have a bouncer that you can see things you can go and look at the eavesdrops you know and often you know you'll be in a conversation and someone will send a link to the exact place in the eavesdrops so you can catch up real quick. So not the latest and greatest tools but at the same time they work because it gives us a functionality. So those are some great things from upstream that are community related. But yeah talking about onboarding we've run in the past the OpenStack upstream institute before summit and also at like OpenStack days. Basically it's a one and a half to two days of onboarding teaching you about governance teaching getting your system set up. All the things that help you to become a contributor. At summit you know I've often done the get in gear at lunch and learn just again getting people in a room and being able to walk around and help them get configured. OpenStack is very involved in Grace Hopper conference you know in the open source days there so anywhere that we can get out there and help people get them to be a contributor is a great thing. And RDO is the same way in that you know by moving our tools to the same thing yeah it's a different Garrett but it's the same basic tools system. And that kind of calls back to something that you said earlier that I think is really poignant which is that being able to get your hands on these systems and being able to operate them yourself is really pivotal to like understanding these things. And it's really foundational to becoming better at doing these things because it seems kind of nebulous when you're sitting on this side of the screen and you're reading about OpenStack and clouds and all these other things. And it becomes real when you're like turning on virtual machines and turning them off and connecting storage and you know understanding these these processes so like when you talk about these outreach days and you know chances for people in the community to come and actually use this technology. I think that's tremendous because like you know you're absolutely right about people you know needing to kind of interact with it to really understand it deeply. So under Open Infrastructure Foundation there's a project called Open Infra Labs which runs big labs at universities that you can check things in and check things out. But one new project underneath that is Operate First which is the ability to check out and you know get your hands on some open, no shift on stack as David called it in the chat to be able to use some open stack in a larger environment than just a proof of concept. The proof of concepts are always invaluable in that you can get an idea of what it's going to be and what you need and also as I said teaching you how to get your hands on things but the advantage of something like Operate First is that it's larger scale. So you can feel what it is to have 50 compute nodes out there and what it takes to run it. So there's a lot of thought into the projects that are under the Open Infrastructure Foundation and how they all tie in. Operate First initiative, sorry go ahead. You know that it relates to everything else. Yeah I was going to say that Operate First initiative is very ambitious but I love what they're shooting for in terms of you know kind of opening up that community side of operating these infrastructures. You know it's tremendously ambitious and I really hope that it kind of works the way that they're talking about it. I think it's got a good team behind it. Karsten Wade is driving that from the community architecture side and he's got so much experience. And then you've got the Open Infrastructure Foundation and what they're bringing to the table to help grow it and help maintain it and make sure everything's open. And about 50 minutes or so? Yeah I think you know technically we have maybe seven or eight minutes left before the end here. Do we have any more questions from the chat? I knew there was a good chance this was going to be a quiet session. Well our community is a little virtual down. Indeed well I mean it's been a great conversation you know from my side at least. Well thank you I really appreciate it and all the questions as well. And we kind of varied off of RDO to more of the upstream and that's an important one thing to note also is that RDO is kind of a downstream of upstream upstream. So we have the open stack community, RDO and then what goes into Red Hat. But you can also just take what RDO provides aka the RPMs, pack stack and build out your own infrastructure from there. So it's a really it's another deployment method just one step down from the actual upstream. Well I say we give everyone back a few minutes. Okay well Amy Marish thank you very much for hosting today and yeah I hope everyone goes and tries out RDO. Thanks everyone for coming in all your questions and thank you Michael very much. Take care all.