 Hi everyone and welcome to the bi-annual CPE update for the Fedora release party. So this is just a quick overview of everything that we're going to be discussing today. So we're going to be looking at the three Fedora projects that we worked on in quarter three of 2021. We're going to have a quick look at what we are working on at the moment in CPE for Q4. We're going to take a quick glance at Q1 for 2022 and an overview then of the process, that kind of the quarterly planning process that kind of goes hand in hand with that. And then we will have some questions hopefully after all of this. So just a quick introduction then to CPE, the community platform engineering team, we're a Red Hat team that's dedicated to the Fedora and CentOS projects where we contribute to infrastructure and race engineering. So each quarter CPE together with the CentOS and Fedora community representatives choose initiatives to be worked on and then the CPE team is split into multiple, smaller sub teams that work on the chosen initiatives. So just a little bit about me, I probably haven't met most of you yet. So my name is Ellen. I'm working in the Waterford office here in Ireland. I have been interning with CPE since May of this year, focusing on people and process management. And throughout quarter three, I was acting as project manager for the three Fedora initiatives that we're going to be looking at today. And during this time, I worked closely with Ifa Lone to choose our product owner, working on the processes to take the teams and the projects to success. So feel free to reach out either on GChat, email, LinkedIn, Twitter, feel free to reach out at any time. So these are our three Fedora projects that we worked on in Q3. The first is metrics for apps in OpenShift. That was worked on by David, Bipple, and Acustee. The second was data nommer, Data Grapper. That was Aurelian, Ryan, James, and Lenka. And then last but not least was DNF counting, which was worked on by Nils, Adam, and Patrick. So metrics for apps on OpenShift. This project was a way to gather metrics on applications that use OpenShift in Fedora. So the goal of this initiative was to deploy OpenShift for in Fedora infrastructure and start using Prometheus as a monitoring tool for apps to be deployed on OpenShift. So the team deployed OCP 4.8 in staging and production. They configured a cluster with OAuth OpenShift container storage and other needed operators and conflicts to support Fedora workloads. They automated the process of OCP, deployed with Ansible, and deployed and configured the user workload monitoring stack. So very well done to them. That was a really successful project. Secondly, then we had data nommer and Data Grapper version 2. So data nommer is the DB used to store messages on the Fedora Message bus. Data Grapper then is the API with a web GUI that allows users to find messages stored on data nommer. So the goal of this initiative then was to upgrade these applications to use Fedora messaging and increase the performance of applications for their users. So the team upgraded both data nommer and Data Grapper to use Timescale DB and both of those are now also running in OpenShift. The prior solution was slow and inoptimal. It was a database structure that wasn't optimal for storing current amounts of data and we wanted to optimize these services for a faster and better performing messages retrieval system within Fedora. We chose Timescale DB as it's an open source relational database for storing time series data and Timescale DB is a post real extension that allows us to take care of large amounts of data that we generate and maintain an SQL compatible interface for applications. So very well done to the team. Last but not least then we have DNF counting. This was used to obtain data for how Fedora is consumed by users and the goal of this initiative was to make the retrieval and counting of data more reliable and efficient while preventing timex and crashes. So the team packaged it as an RPM. They deployed scripts and cleaned them up. They streamlined failures, notifications and leveraged data nommer DB for storing messages in the Fedora message bus for sending. They removed manual intervention when programs crashes and they added CI tests. So the team set out to increase its performance robustness and make potential problems easier to follow. This was achieved by sending out messages on the Fedora messaging bus. So the messages are stored in data nommer and can be retrieved with data grapper and are accessible in the event of a problem. Again very well done. So looking at Q4 then we are currently working on two staffed projects. The first of which is Fedora core OS pipeline migration. So the aim of this project is to make Fedora and the core OS pipeline more integrated within the Fedora community and to leverage the new OCP for cluster in Fedora and for and migrate a pipeline here. And then the second of our initiatives this quarter is sent us WCI and other CI tenants and upstream projects will be able to use Duffy CI more easily and readily. And this also allows other cloud images to be used or consumed from Duffy so there is no maintenance or uploading for or removing and it's a bring your own cloud image. Also in CPE at the moment during this quarter we are working on CentOS stream and ELN and the infrastructure and release engineering day to day work continues as well. So then just to take a very high level glance at potentially what we may work on in Q1 of 2022. So we're in the very initial stages of starting to scope some projects for that quarter. And the planning will take place for that in mid December of this quarter. So potentially we're currently starting to scope with body upgrades and FMN for potentially running with those early next year. And next quarter we'll also continue to work on CentOS stream and ELN. We'll continue to work on infrastructure and release engineering work on a day to day and also Apple and automotive upstream development. So then just to take a quick look at the overview of the process that we go through during quarterly planning. So it's a three step process. We start initially by scoping the process. The initiative is reviewed by a wider CPE team. Any technical requirements are discussed then. Any deliverables are estimated with the ARC team and they can undertake an investigation. And all stakeholder groups or requesters are informed and their expectations are discussed then at that point as well. And then we go to quarterly planning. So projects are investigated by ARC or requester and stakeholder expectations. Hopefully have been satisfied and planning initiative takes place. We work with the wider CPE team and stakeholder groups to prioritize each initiative. And then the initiatives are put into tickets and repos and management team and RPOE first. They work together to measure these initiatives towards mission statements and then prioritize them accordingly. So we are at question time. Hopefully if you have any questions, if I'm unable to answer I will take note of them and get an answer back to you or I think some of the team are in the chat today. So hopefully they might be able to answer your questions there. But thank you everyone very much for listening and taking the time to join us. And thank you to Marie and Matthew for putting this together and for having me today. So first question James, what does CPE stand for? So community platform engineering. If you have any other questions feel free to add them or we can come back to them at another time. Okay Matthew, how can we make non-project CPE work more visible? It's actually interesting actually. But something we could definitely open the floor to. I think we do a very good job within CPE on a weekly basis. We host a weekly call and everybody speaks about the work that they've been doing throughout the week. So maybe there's an option to maybe discuss that with the wider community. So Zach, how can we create an open-ship single no cluster with the door? So that's a technical question. Hopefully there is a reply there from people. Yes, thank you. So there's some questions in the chat as well. Do you publish the JIRA boards on roadmap support or work? We don't typically use JIRA for the quarterly planning. We use MIRA boards. MIRA makes those available at the time. And we have public either GitHub boards or packet boards as well. Okay, Matthew, if groups in the community have a project, they would like CPE to work on how should they propose that. Okay, so Ifa is our product owner. I would maybe get in contact with her and send it to her. And then it can be added to the backlog or she can hand it on to ARC. We can do an investigation there at that point. Hey, I do have some points to add. If you don't mind, Ellen. Yeah, please. Go ahead. And sorry if we all hear Ellen's voice in my microphone. I'm using speaker. I was not prepared for this. So Matthew asked how do community come to us with new projects? We do have initiative repository where you can open an issue and we work with you to refine exactly what the initiative is. And there's an actual process of how we take those initiatives. Our product owner as Ifa mentioned, sorry, as Ellen mentioned is Ifa and she takes those initiative requests. She works then through refines and works with the team and other stakeholders, which was Fedora Council and CentOS board and internal Red Hat stakeholders to prioritize those initiatives. And depending on our strength of how many developers and operations are operational members are free to work on, we take those initiatives every quarter. All of these initiatives, most of them at least come through the same process. And I'll be sharing the repository link where you can open new issues for initiatives in the chat in a minute. And another question about using OpenShift on Fedora. OpenShift runs on Red Hat CoreOS. And I'm not sure I think five or six is the minimum node requirement between compute node and control nodes together. I'll also share the link in chat of exactly minimum requirement of OpenShift. Thank you, Vepal. I think all questions have been answered so far. Correct me if I'm wrong. I didn't see a roadmap for Arch64 here. Does that get done by another team? I'm not actually sure the answer of that question. If anyone in the chat has that answer. Sorry, what question is that, Elan? It's in the chat, Rupert Bailey. I didn't see a roadmap for Arch64 here. Does that get done by another team? I'm not sure the question is about exactly where Arch64 is. Is it the image release? Yeah. Thank you, Matthew, for providing that answer. In chat, I have shared where you can create any sort of request, by the way. Do we have any other questions? Or does everybody have their question answered, at least? Yeah, I don't see any more traffic here. So I think we're good to go. And thanks a lot, Elan, by the way, since I'm on the call. Yeah. No, thank you, Vepal. Thank you for your help. Yeah. Thank you very much, everyone. And I hope you'll see you all again soon.