 Alright, thank you all for coming. This is a lot more people than I was expecting. For those of you who don't know me, my name is Brian Stinson. Thank you for coming to this talk. In all honesty, this is Brian Stinson's talk. He could not make it. He is stuck traveling, so I am going to do my very best to do service to his talk, and we'll see how this goes. We have a number of people in the room to thank for CentOS Stream and for the stuff that we're doing for CentOS Stream, so thank you, Mike and Tim, for not firing me out right at the suggestion for this. I walked into that one. So CentOS Stream, the progress so far. Let's talk a little bit about what people think happens when they look at CentOS as you know it traditionally, as you look at Fedora, and as you look at Rell. Brendan Connoboy has given a number of variations on this talk with his Penrose Triangle for trying to explain things. I was told that if I use the Penrose Triangle diagram one more time, I was going to be shanked, so this does not have the MCSher drawings in it. There is no triangle here. See? Alright, thank you. Welcome. The traditional feedback loop from CentOS to Fedora, if it happens at all, because that's kind of a painful loop, takes forever. So the real happening here is the back and forth in Bugzilla, bugs.CentOS, people who file bugs against CentOS for what they perceive as Rell bugs tend to need to be duplicated, then refiled again in Bugzilla. The patches get ignored if there are patches submitted. There's a lot of stuff here. It's a lot of back and forth. I don't need to read the slides to you. It's kind of complicated. The releases for how this works are fairly painful. This kind of describes the majority of the workflow around it. Bullet number two is kind of where things fall down. It stops a lot of the time. Sometimes the package maintainer stops being responsive. Sometimes they look at it as, oh, it's CentOS. It's not really Rell. I don't need to care about that. There's a variety of stuff back and forth. None of it actually benefits the end user in any case. And so that's part of what we want to change. Because helping the end user benefit CentOS, it benefits Rell. This has follow-on effects across our entire ecosystem. One of the things that we do see in CentOS periodically, users will jump between CentOS, Fedora, and Rell. And so one user has a bad experience in one side, and they equate that to other pieces of the ecosystem. And that doesn't really help anyone. So what we want to do, and the way that we've been referring to Stream, is CentOS Stream is what Red Hat intends to put in future versions. And so this is kind of where we started for the design around this. And what would we want a feedback loop to look like? How would we want CentOS users to contribute to the Rell ecosystem in a meaningful way? How does Red Hat see value from what CentOS is providing if they're not getting money? How do we make this work? And so what we want CentOS to be is a very narrowly focused version of what Red Hat intends to put into the next Rell release. It's intended for open contribution. We want the community to be able to provide fixes, feature enhancements, ideas, use cases, commentary. These are the things that we want to see. An example of this would be the newer Python modules that have landed in the beta for Rell 8.2. If you've taken a look at that, there's a new Python module coming out, Python 3.8. If we'd had that in Stream, we could see if that works across the layered products, how that happens, these are some of the things that we're intending to build. Right now, we're already looking at doing that with DNF, with RPM. There's a newer RPM in Stream that supports the Fedora Z standard packaging. So we're able to have a little bit more communication back and forth. These are some of the things that we want to see for enhancements for Stream so that people can get a better idea of what's coming next. And if something is broken, they can let us know. They can help us fix it. We can make the entire ecosystem better. And this is a great way to notice and test against features that are about to come into Red Hat or into Rell and for Rell to get feedback from real-world use cases before it lands in the production setup. I'm sorry? Can you explain that a bit more? For Stream, OK, I'm being told I have to repeat the question and I'm bad about this. There are two next minor releases for Rell. There's a 7x, there's an 8x. For the purposes of Stream, we don't care about 7x. For Stream, we started with 8, and we're moving forward for 8. So 7 is going to continue as it always has. We're not going to mess with it. We're not going to worry about that. We're looking at the development right now for 8. So CentOS Stream is the next minor release for 8. So right now, we're looking at 8.2-ish give or take. There shouldn't ever really be a point in time where you could say this is exactly the snapshot for 8.2. There will always be stuff in flux. But it should give you a rough approximation. I will throw. Since we're allowed to use version numbers, I'm going to throw that to the person who makes the decisions in the back of the room. Mike, would you like to answer that one? So to reiterate that answer for the recording, there's going to be a brief period of time where there's an overlap for transition. But as Red Hat releases the next major version, Stream will then move to track the minor versions of that next major version. So when 9 comes out, there will be a brief transition window. But then we'll start following the 9.1, the 9.2, the 9.1, whatever. It's important to note that we're looking at this for use cases, and we're not intending to jump in the middle of any partner relationships, things like that. This is intended to be very public development, very open stuff. And this is a place where the SIGs, the Special Interest Groups, can consume this work and test things out on stream so that they're sure that it works for that next minor release. This should, in theory, provide a much smaller iterative step for development for the Special Interest Groups and for the layered projects, rather than the big step that they have for the current minor releases where 700 packages shift out from under them on a Tuesday. Instead, it's a lot of little shifts where it's a package here, a package there, as it progresses. So it should cause a better, more even workflow that's always kind of constantly moving. So how do we get to where we want to be for this? Right now, we're doing the initial foundational builds. Stream right now is effectively 8.1 packages with about a half a dozen newer things from what we intend to have in 8.2-ish, we guess. Right now, we've got the newer system D, newer DNF, newer RPM, things like that. We want to get to a place where we're starting to pull, catching up to the rel development for feature development, and then pulling ahead of rel and constantly cycling that through. So we've got a bit of work to do to get there, and this is going to take us a little bit of development time. Right now, we're still doing the source code development, or the source code delivery the same way that we did it for CentOS Linux, where it's take the source RPM, import it into Git, run the build manually. These are all things that we've kind of got to automate as we start working this up. And so we are doing that over the next couple of months to build this automation in so that we can start using Git hooks, triggers, message bus, things like that, to start cycling these builds automatically. There's obviously a lot of technical challenge in that that I'm kind of glossing over if anybody who's maintained a build system would look at me kind of sideways on that one. And as we ramp up, yeah, here's the listing for what we've got so far. We have a few more packages that we're going to be pushing, I believe next week to help increase this list a bit. And this gives us the kind of starting point for what we're looking at doing. Let's see, what else do we have in his slides? Part of the big issue and the challenge that we have to do as part of making streamer reality is a lot of internal to Red Hat policy work. There's a lot of stuff that we've got to work out with the REL engineers, with the subsystem teams who own different components for things, and a lot of structuring that's mostly just kind of cleaning stuff up because on the REL side, a lot of that was never really thought of as a public thing. And as we're moving that development into the public space, we need to make sure that we're not putting inappropriate comments in Git commit messages if anybody's ever sworn for, like my god, I need to fix this typo again, things like that. We want to be a little more conscious about what we're doing, what we're saying, how we're looking at the code, making sure that we're not breaking embargo or anything like that for CVEs. As the automation happens, we'll have more packages catch up. And we expect to be piloting contribution workflows very soon. We know that it's going to be painful early on for the first couple. We're hoping that several of you will bear with us through that pain and help us smooth that process out. The end goal for getting ahead with Stream is a place where Red Hat engineers and the community can work together in a public forum and help do the development. It's still going to be very opinionated. It still obviously has to end up as REL, but we want community members to be able to contribute to offer features, suggestions, things that they'd like to see, lots of workflows, things like that. Are there any questions so far? I know I've rambled kind of quickly at you for this. Really? That's shocking. I thought somebody from the Red Hat org would want to throw something at me, or community people would want to stand up and say, but I've got a fix that I put in a year ago and no one looked at it. So the big thing right now, if you are interested in CentOS, if you are a CentOS user, please go try out Stream. It is available now. It's roughly equivalent to what you're used to working for and it will start to slowly pull ahead. There shouldn't be anything jarring in it. There shouldn't be anything wildly outrageous. All of the traditional promises for the REL-based codes still apply. If you find something that violates anything you would expect to be broken in REL, then obviously it's broken in Stream. Let us know, that's something we want to fix. Yes? So the question was as we pull ahead of REL, how do we handle potential breakage because CentOS has previously been shielded from that? Honestly for a lot of that, it's going to involve public CI and public testing and Steph Walter and his group have been very forthright about being willing to help us set that up, put that in place, but yes, we probably will see a little breakage. Keep in mind that the developers are still REL developers. They're still angling toward, like all the same rules still apply, but you're right, we may see a little bit here and there. That's something that we will work to address as quickly as we can. If it is broken, we will fix it. So right now we are working a transition program for CentOS StreamBugs to be in bugzilla.centos.org. Ben Cotton, who is here in the audience and I am calling you out specifically. Oh, right, I'm sorry, I'm used to doing that said in my head, bugzilla.redhat.com. We have that bug tracking area set up there. Those bugs are going to be essentially tracked and worked there. We expect that there will probably be a private copy of that bug made at least initially while we figure out how to do a lot of this stuff and then it will be answered back in the public section. Do I have that right Ben or do you want to correct me on this? So if you file a bug against Stream in bugzilla.redhat.com now, it will be acknowledged, it'll be efforted. It shouldn't hopefully be a place where you don't get any feedback at all for the next couple of years or whatever. We're desperately trying to avoid that. We know that a lot of people have opinions about bugzilla bugs now and that's not something that we're looking at duplicating. Mike. So the question is what do, so the question is what did the special interest groups do with CentOS Stream? And the answer that I would have is consume it, test it, build against it. Lots of the layered projects that we have over RDO, things like that. I assume that they would want to know if Red Hat is revving a virtualization thing with KVM and it causes breakage in RDO and Stream would be a place for them to see that before it's actually released and to work with Red Hat to get that fixed kind of quickly. The same thing for Ceph, for Cluster and the Storage SIG for other groups. It's a way to work with us within the CentOS build system to test things out, to see what's coming, to make sure that those features are there or if they want to add features in, that's the place to do it. Ceph, if you build software that runs on RHEL and it doesn't necessarily have to be in a special interest group, although we would prefer you working with us on that, CentOS Stream is a way to test and validate and, or not validate, but a way to test and see if it will work on the next RHEL or if there are bugs, things that you may need to change, things that maybe Red Hat has broken that you can work with us for fixes, that sort of stuff. It's a way to get a preview and see what's coming next. Yes? The Stream currently is effectively an 8.1 installer with a much newer kernel and then as an update immediately, you'll see newer DNF, newer system D. Hopefully next week you'll see the newer Python modules if Python is a thing that you're using and the vision is longer term, all of those packages will be slightly ahead, all of it. In bugzilla.redhat.com with CentOS Stream as the project, we are not currently doing base container images for CentOS Stream. What we have discussed doing was taking the UBI that Red Hat already produces and dropping the CentOS Stream repository on top of that, but right now we're just doing, I believe virtual machine images and installers, we're not doing containers for it. If that's something that we need to change, let us know, we're open to feedback and suggestions on this. Can you run CentOS Stream on a dream piece of hardware I believe is what I heard? We don't have a mainframe so we don't currently run anything on it, so at this point, no. I don't have a spare $3 million to buy one, I'm sorry. Brendan, right now CentOS Stream runs on ARM64, PPC64LE, x8664, and we're not doing ARMV7 yet? Or... Okay, we will have ARMV7 for the CentOS community, we have a couple other things to work out around that. That one will be coming, but it's not there yet. Yes. It will be ARMV7, 8.6, 8.7, 8.9, et cetera, et cetera. Then we don't need that anymore. Well, how can I understand that? I don't see it yet. So part of it is keep in mind that as well as older, I think it was PACE2 and maintenance and hardware, it's just not getting any bigger. So at that point, there's really no sense in having CentOS Stream, because even if there is some major feature that a partner's going to need, generally it's got to be an active guide to get that into CentOS. So keep in mind that for Stream, it really is about new development. Are we going to break your stuff? Do you have something to mod us over? Do you break our stuff? How did that come to your development stuff? Whereas in the older versions of REL, they really do go into the maintenance space. And keep in mind, we haven't actually gone through this. It could be that no PACE needs it all. I mean, we decided we need them on the longer end over that, and we do need them to take it out. You know, that's just what we're planning for right now with the team that we've got and most of that. To loosely reiterate what Mike said for the recording, CentOS Stream right now is fairly experimental. This, we just announced this, what? August, September, somewhere around there? September, and we are still trying to sort lots of this out. The announcement was basically, hey, we want to do this. We're going to do this very publicly. So a lot of the stuff you're asking about, we haven't sorted out the details on it just yet. This is an experiment. Right now, the anticipation is that transition period. Maybe we get enough feedback that we need to extend that slightly. Maybe it's not required. We'll find out when we see more usage and we see what people are doing with it and how they're using it. This is going to be, so the question is, is this expected to work with updates? And this should work kind of the same way you would expect CentOS Linux to work now where you progressively get updates and for the most part with CentOS, we just say it's eight. We don't necessarily want to focus on it's eight, one, eight, two, whatever, because we don't really support those minor versions. So you will get updates, you will see those intermediate builds. Several of the packages that we released, and I'm being told them out of time, so I'll wrap this up quickly. Several of those builds that you see might be intermediate builds. They'll be released, they'll be tested. Red Hat may ship a newer version and will be ahead of that newer version. So yes, you should see updates. You can install it. It will continue to roll forward. Thank you.