 For anyone who doesn't know me, I'm Steven Gallagher. I'm a Red Hat employee and I've been working in Fedora for over a decade now. So, what is, what is Fedora Server? In what is now apparent to me is the distant past. We used to have only one version of Fedora that we released and shipped. This was six years ago now. And over time it had become apparent that even though Fedora's beginnings had been in the server space, people wanting to run servers on commodity hardware, time had passed and in many ways the desktop had taken over the Fedora community and it was much more focused on producing a desktop distribution than it was giving a place for people to develop server technologies. So we did what was then called the Fedora Next Initiative which involved splitting the distribution into a variety of different additions, one of which was Fedora Server Edition which was going to be focused on specifically server technologies providing a base platform for your, well the traditional metaphor is the in pets versus cattle but I prefer to use worker bees versus queen bees because you're never gonna have an environment that doesn't have at least a few queen bees in it no matter how modern you've become. So Fedora Server was meant to develop those technologies for the queen bees and for a while we were doing some interesting things but they were pretty much, the cockpit project is the major success that we had early on and that has expanded out and it has been a great success on its own, has found a very big following in the rail community now. Some of our other efforts did not go nearly so smoothly but ultimately Fedora Server and I say this with a very heavy heart has failed as a project. It is, at this point in Fedora's life cycle, it is running, it is sitting on life support. I'm pretty much the only consistent contributor to the project and I'm more or less just keeping the lights on at this point. We've, I've tried several times to reach out to get more community involvement but I think, well, every time I've done that, this has been the result. For those who don't understand the reference that's a critical failure in a role in Dungeons and the Dragons. What I think is part of the problem is that time has moved on and the problems that we just set out to solve are either solved or no longer particularly relevant in the space. Added to that the fact that we couldn't really guarantee an extended life cycle which is something that is more or less basic entry into the server space. We tried for a long time to explain that where we couldn't necessarily maintain the same version number for extended period of time we had gone to great lengths to make sure that the upgrade process was smooth and wouldn't break on a regular basis. And in fact, we've been through several releases where our Fedora releases, our Fedora upgrades broke fewer things than those rel point releases. We were simultaneously proud and ashamed of that. But at the end of the day, if you can't say this version will be supported for three years people don't pay attention. So I think what we need to do is we need to bring Fedora server back to the drawing board. I think we need to decide anew what is its purpose and if it doesn't have one or if it does what is it. And come up with a new strategy for how to develop it ideally in such a way that it encourages more people to contribute to it. First and foremost, I don't think it will come as a surprise to anyone if I point out that the not terribly subtle intent initially was we needed some place in Fedora to very clearly be a staging ground for Red Hat Enterprise Linux. And while for a long time because of political reasons we couldn't say that outright, it is generally true. And I think that it may be the time to make that, you know, revisit this as a formal requirement as opposed to a wink, wink, nudge, nudge, maybe Daddy Shadowman wants something. But I'm here to listen to ideas. I've got, okay, there's one. I just had a comment, so is it a cloud instance? Is it a vagrant instance? Is it not those things? Is it, you know, like that's, I think it's also been a big challenge with server. You know, it's like, what is its goal? And it's not gonna carry those other goals where everything just kind of falls in. Where do those go instead? Right, okay. We're not recording, so I'm not gonna bother repeating that. I think everybody could hear Langdon. He's got a good set of lungs on him. Yeah, I mean, I can tell you what the goals were initially, but again, my perspective on this is that those are no longer necessarily valid. And I think what we need to, I think the first thing we need to do is we need to go back and we need to scrap the existing PRD, which is, I think there might be a the in it that's still valid, but that's about it. All of it is irrelevant at this point. We no longer have a concept of server roles. I think the only thing left in it that is still useful is the requirements that sets down for Cockpit. But I'm not sure where to begin because it's easy to say, okay, we need some place for new server technologies to be built, but we also need some, if you're gonna build something, you need someone who's willing to test it. And in order to have someone who's willing to test something, you have to be giving them something that solves a problem. I am really hoping that some of you guys can just express a good problem that we could be solving here because we're in an odd place, like I said, because we have to have this addition as it is useful to our primary benefactor, but we also need it to be done in such a way that it is actually useful, both to us, both to the Fedora community in general and the Red Hat consumer directly. And I'm not loving the silence. Yes. Oh, I'm sorry, I was actually also going to point out that there's another aspect to all of this that makes things even more fuzzy, which is the fact that almost anything we could do in the server space is going to be largely irrelevant in three to six months. And the reason for that is that the Apple project is going to be shipping modules for REL-8 that are built out of the Fedora environment, the Fedora build systems, which means that fundamentally, once CentOS 8 launches, no one will ever install Fedora server, they'll install CentOS 8 and then whichever Fedora modules they need from Apple. Okay, so yeah, new hardware is an interesting point. I'm not sure if that's a... Mixed generation hardware. Yeah, sorry, a couple of additional hands were going up. I was just letting... Okay, this gentleman's been trying to speak for a while. Fedora project. No, what I was saying, I wasn't actually implying anything about CentOS currently. What I was saying is that what I imagine will happen is that they'll take that stable long-term platform and then because of the primary reason that the very few people that use Fedora server today use it is because it provides newer packages than what they can get out of REL and they need that for their environments. But with the appearance of modules, they can now have that stable platform and their new... To a certain degree, yeah. Not everything, but my point is I think that that is going to eat into our already tiny deployment. Just was people curiously working here that somebody needs whole machine? This is what they're doing with Fedora because so far, this is the most brand-based environment to upstream developers when they want to cooperate on system-wide level. Not other distribution actually provides this project for our students. We cannot use data, there's no possibility to integrate on data, anything that... So it's a middle ground that we have in Fedora and for us, Fedora server delivery is not necessarily ISOs and images, but we have deliveries that we can define in terms of Fedora server speed. More interesting than probably for taking Fedora setting deployment, there are certain amount of that means that food is, but it's more valuable to actually developers to see how these work together, how they connect together, how you can play both server and decline side in the same way. This is so much valuable that it is allowing multiple upstreams that come from Fedora. Now the other problem is that with the roles, for example, I'm pointing to the role. Yeah, there was a pun in there. Is that Ansible basically overtook that niche and if you would do some sort of affirmation of how you would deploy something, it's now Ansible roles integration with the particular environment that's more available to actually happen is because of them, they can reuse the same roles on different distinctions to react. Without, well, in most cases, it wouldn't be without adaptation because there's good level of adaptation in the place Ansible stuff. Yeah, I mean, it did lose out on one aspect of the roles that was intended to be just part of the cockpit overall, everything on the system should have an API idea that it should be possible to administer a single system without having to use an overpowered configuration management tool. And we did, we lost out on that, but truthfully, yes, Ansible is the better choice for most things. And it's effective. I pitched the same thing, the cockpit team disagreed and we're not gonna rehash that argument today. Is that the only one? Langdon. So I was just gonna say, particularly the point about kind of the hardware refresh problem, some of the CentOS team members actually run Fedora Kernels on with CentOS, right? Would potentially an idea be for Fedora Server to embrace the CentOS 8, killing it in a sense, and Fedora Server actually produce kind of core bits that would work with CentOS 8 to provide for newer hardware. So in other words, the server wouldn't actually be its own thing as much as a set of big module strings that you can plug into CentOS 8 that would let you use newer hardware. So it would become a CentOS variant? That's what you're suggesting? I would still, in a sense, it's still Fedora Server, but I'm just kind of saying it's like embrace the CentOS 8 part of it and the problem space that you're talking about is where you wanna actually refresh new hardware and you wanna kind of make sure it's gonna work. But then you have... I don't know if that solves the same problem though, because like Alexander was saying, that there is something to be said for integrating from top to bottom to have that upstream that will eventually become rel and CentOS 9 or whatever comes after 8, you know, because I can't make forward-looking statements, so it might not be 9, who knows. It could be ME for all I know. Yeah, that would be terrible. Anyway, but I think we still do really need to have that integration from top to bottom somewhere. I think there is some sense in trying to make a focus, you know, supporting new hardware, but... Wandering around trying to make people support hardware to make people support, make people at Red Hat support hardware that doesn't exist yet and to do it... That gets really hard for, actually, mostly for legal reasons in Fedora is because if Red Hat isn't the one backing it, there's nobody who... There's an awful lot of NDA type stuff for a pre-release hardware that makes things really difficult. And that makes it hard to do that in Fedora. Right, but a lot of it is still kernel enablement, which means you're still sending patches upstream that suggests... Oh, well, no, I'm not saying it isn't. I'm just saying that in a lot of cases, even those kernel patches remain embargoed until the hardware is released. So that's more difficult, not impossible, but more difficult to do in a public open project. Because you either have to submit them and have them tested by the community or completely hide them forever, at which point you're not really working in the community. Custom tweaking because you have bonded interface with some specific metanox card and whatever. And in that case, you say, okay, you as a customer, we provide you with the ad nodes and we just run the open shipment of your ad nodes, but we don't manage it, so we don't take that configuration, we don't care about the days, rollbacks and these kinds of stuff. So you're like, for sure, there's still some kind of add-in if we cover it. But then the problem is that looking at this from the Fedora for the View is that we are trying to provide the equivalent of that with Fedora for us, but not the equivalent of well. But then at that point, you're kind of actually much larger competition because you are providing traditional servers about. So as you say, a queen bee is set up. And that one may work in and out and it's useful information up to you. Yeah, it's worth examining, but ultimately I think the queen bee side is still gonna look a lot like what we have right now. I mean, one of the things, and I'm running low on time here because unfortunately when rescheduling this talk, I had to be moved from a 50 minute to a 25 minute session, is what I'm doing right now, just keeping the lights on, is anyone benefiting from that right now? Because I can continue to do that for as long as needed, but it's feeling like it's becoming a diminishing value and I wanna figure out how to revitalize that and ideally get somebody else to do some of it so I can occasionally take a vacation without getting paged. Okay, thank you Dominic. I just want to suggest to me that we can ask, why are we related to the server and user? And then we could have an alternation of testing those scenarios as a release and release gating for the server which becomes virtual release. It's just gating all these scenarios and all this stuff. So we had that discussion where we talked about server roles and more international things, but with the tests, we have a place where you can codify those requirements. You can change them and see the results and there's an actual feedback that goes both ways and you have the dialogue that you need to have. We do have this for the main controller related things because it's stretching actually not from the top down. It's actually wide from server to the work stage because it tests the hero or the non-hero team or the folks, single sign-on. I'm fond of saying that if an edge case exists, free IPA will discover it. Yes. But we don't expose them, we have benefits unless they're in some way, including next scenario or in the future. And I think this overarching story, like this is the point to say, if you care about the server and the whole and you don't want to talk to 10 different teams and contribute to their individual tests and different requirements, like this is the server use case. This is the server use case you can break. And when there's thinking ahead, you can say, with this move to door 31, 32, 33 release, we support this story passes. This is something that works without caring about, but if you dive down, you have all the individual pieces, but you have the story defined as a whole. Yeah, and maybe that's a good way to go and you're right, that may actually inspire some people to come in and contribute too, at least to write some of these tests because that is their usage downstream.