 Then I suppose we should get started good afternoon. I'm Steve Gallagher. I work on the Fedora server SIG For the most part I act as its chairperson So what are we going to talk about today? I'm going to go through Why did we create the Fedora server? what What is our ultimate goal with it? How are we getting there and last but not least where did we go so so wrong? So let's start with a little bit of a history lesson when When Red Hat Linux was first created back in the days when I still had hair There it was very heavily driven by hobbyists and small and small server admins people who wanted to get Things done people wanted to support their engine their engineering habits or their Or their science labs and things like that and over time as Linux and the open-source community grew and especially became Fedora and our Fedora community grew It kind of started to morph. I'm getting off the camera. It kind of started to morph into a More heavy desktop focus Things like the GNOME project and the KDE project both started taking up all of the mind-share of people who thought about a Linux distribution They were thinking about how do I use it to replace Windows? How do I use it? To get a better to get a good Unix experience without having to pay, you know thousands of dollars for a Mac things like that and while this was happening It started to it started to cause Those longtime server admins to be kind of pushed aside all of the new functionality all of the new features all the cool new things we were doing they were all in the desktop space and It got to the point where Server administrators were starting to become the party of no in the in the Linux community They're kind of it was kind of a matter of They weren't getting an opportunity to innovate the way that they that they really should be and What they were ultimately getting getting to is no no please please don't make Please don't open the firewall by default. Please don't do this. Please. Don't do that. It's bad for servers Was about all they could manage to get through as far as changes in the Fedora project so when we embarked upon the Fedora next program one of the things that I pitched at the time was that We should consider and we ultimately did Changing up our set of deliverables so that we had a few primary At the time we called them products That would be Fedora workstation, which would focus very heavily on the desktop and a use cases Fedora cloud, which would handle this at the time new and emerging public and private cloud environment and the Fedora server Whose goal would be essentially to really focus on the data center administrator of of our classic history and Like I said this as all of you know here that idea Took took wing we did we did split these out and so we built an Environment where the server admins now had another voice they had a place where they could say hey Now that we've got this our own deliverable Here's some cool. I did cool things we can do that the desktop people would have said no about Or the desktop people wouldn't have cared about and we can and we've started talking about some of that and One of the things we did there We came up with a few very specific Programs that we started that we started to produce sorry I lost my place and I'm catching up to myself That would be it would be heavily focused on improving the The data center OS things that would we hoped ultimately flow down into future versions of redhead Enterprise Linux And get him and pick up that audience as well so I'll get to some of the details on that in a moment, but What is the ultimate goal of the Fedora server? Edition and the SIG we debated this for a very long time in when we were originally doing the We had a series of PRDs of project product requirement documents that we Submitted to the council a number of years ago That described what exactly our goals would be and we've revised them over time And I think the most recent revision of our vision statement is Anyone should be able to confidently obtain Configure and deploy software services that address their needs using readily available and trustworthy recipes So that's a little wordy for a vision statement, but I think it's about as succinct as we can make it What we want is for anyone and I mean anyone to be able to turn on a machine and With a minimum amount of education Figure out how to do a Common set of tasks. I want to I need a database server for my for my house I need I want to I want a simple web server to show off to show off my my band's cool jams and We really have never had that The example I like to use is Microsoft Windows for all of its flaws of which they are legion They did one thing very much right when you install Windows server You log into it for the very first time What happens is it comes up in a graphical environment and it brings up essentially a wizard It gives you a list of things about this server. Here's its current status Here is a you know, here's a here's a set of links to say hey Here's some stuff you might want to do with this server click here and do it You know what happens when you so when you installed a fedora 19 server and then you logged in You got a blinking prompt You know what happens if you type help at that prompt You get the help for bash Not for the OS bash This is not a you this was not a user friendly experience So in fedora We came we decided that we really needed to do better than that We needed to find a way to make the experience better at the beginning for people and so Nowadays even if you install a headless fedora server before login even you will now be prompted with a Login URL that you can choose to use instead of typing the login at the local console and you'll get cockpit Cockpit is Really cool cockpit is very much among among many other things cockpit is our answer to that Windows server manager login a Quick glance on a cockpit you get Usage statistics you get that you can find out and if it's part of a domain join it to a domain You can change the networking configuration. You can change the storage configuration You can interact with kubernetes and most in recent versions You can it has an se linux troubleshooter built in now, which is fantastic. We have a lot of really cool features Include we have we can manage system d services. We can manage logs and We can do a lot of that from cockpit This was a huge step forward because we've now actually got up. We've actually got a story. We can tell that says hey It's not scary anymore We can take this and we can take this to a high school and say hey Let's start. Let's start teaching these students how to set up their own domains how to set up that how to Set up a database and they can start doing some of that Without without a whole lot of prep work a whole lot of understanding of how command lines work And what the hell bi is and why do I have two os's one called one called fedora and one called emacs So Cockpit has been a big piece of this but We did in fact actually come up with a lot of Specific things that we wanted to fix now as you can see here. It's very clear. You can make out absolutely every bit of that I'm sure What we did is we found a variety of different places where we had a poor user experience a poor ability to for people to pick up and understand it and We realized that effectively these came down to being what we decided for a time at the time to call Roles it was a series of things that we wanted the machine to be able to do and we wanted to be able to set up a common well, you know well thought out Security best practices way of doing it. So originally we came up with an idea called roll kit Which was a simple D bus service that was essentially a server oriented installer generalized installer and we had a prototype that Was able to deploy two things It only it was able to install free IPA which was really cool It was one of the earliest times we were able to hand the system to people and say free IPA is one line is a one-line install and it would It wouldn't do replicas. It wouldn't do it wouldn't do ad interaction in Sorry ad integration with active directory, but it would give you a simple home office Domain that you could that you could use and Just and just get started with your with your own small small business for example the problem we had with roll kit was it It was a bit too generic and it was also a bit too specific at the same time. It was It was a very generic Implementation of an installer. It was simple. It was in Python. It was easy. It was fairly Well, it was fairly complicated to create a plug-in at the time. We had plans for how to make that much simpler But at the end of the day what happened is that we did not get The outside contributions we were expecting and hoping for we did not get Inside of red hat or outside of red hat We did not get anyone writing server software that said oh, let me help How can I write how can I write a roll kit plug-in so we can get that? Going and similar at the same time we had a resource problem from the cockpit side who decided that who just didn't have the The cycles to try and implement the ones the roles we had already created in the UI So what we ended up with was yet another command line tool That was really useful only for two for two servers So as of right now roll kit remains on life support mostly because it's still used in automation In fedora land for doing a lot of the automated QA tests for release validation But we are planning to retire it probably at this point in fedora 28 Because I haven't had a chance to work with Adam yet to remove those from the from the QA environment What we are going to replace them with however is a new ansible based system that that Maria Sevolmer of the cockpit project has been working on and is trying to Trying to make a fairly generalized installer as well But do it through an a through a series of ansible of well-known ansible scripts that are powered That are generated originally by cockpit, so it's going to be a cockpit originated project Which has now a very wide and vibrant community We'll have them create they create these models set up the set up their the domain controller set up the the database server and then Apply it, but also be able to output an ansible script that you can use if you want to recreate this or modify it and instead instead of deploying it Be able to output this and then throw it on a pointed at a cluster and say go and things like that load it into an ansible tower and manage and manage an entire data center with this stuff and it'll do the It'll help you pass that initial hurdle of learning how to use ansible But we'll be able to also provide a nice simplified UI for the for beginners or for not for novices coming from another operating system who wanted to do it want to get Things where I get things working in the door server So that I think is going to be really interesting It's still it's in its very early phases and I'd love to hear I'd love for anybody here who's interested in that to join the cockpit to Bell mailing list and and Provide their feedback on what they would like to see from a user perspective in particular because right now There's some there's some user experience design going on. They have a they have a dedicated UXD person but There's not there's a lack of subject matter expertise in terms of people who want to actually do those deployments So if you've got any ideas on how that should look or feel or just want to contribute because it's Really cool project. I encourage you. Please join the cockpit to Bell mailing list Beyond that other things that we have worked on this year Remember, I think there was something. Oh, right boltron So the other really big thing that we have worked on in Fedora server this past year was We decided given that our a given that we had kind of faltered on our original roles plan we needed to find another place that We could we could take the server that into its next stages and with modularity initiative going on we realized that Servers are one of those places where modularity feels most natural Everybody wants to run their this really cool. No JS application, but they really don't want anything else in the OS to change They want to make sure that they have late. They have no JS 9.7 which doesn't exist yet and they want to have You know the latest NPM libraries, but they really don't want they really want to firm base to run it on But then there's also the set of people that really really really want the latest ACVD But they're okay running an old node JS because their application was written by a contractor They have no idea how it works, and they don't want it They don't want it to change for a couple more years until they can until they can hire a new contractor Modularity allows us to address some of that too fast too slow problem By allowing people to pick a you know pick a host that's fairly stable and then pull in whichever old or new versions of the Frameworks they need to to actually run it So we built a prototype that we called boltron and I have to give credit where it is due I don't know if Stephen smoojin is currently in the room, but that was that was his brainchild We were kind of bike shedding on the on the project names, and we came up with well modularity We've got a whole bunch of parts that are coming together into a greater hole So that's kind of like boltron, but we're also doing kind of a hacky job right now So we'll we'll say it's also kind of bolted on So we came up with boltron and it's kind of stuck and I kind of hope it continues I'm thinking maybe we rename it to the boltron say what do you guys think okay? I Will I will bring that up at the next meeting So our next stage is our next steps there are we took we have this prototype it was Functional but not shareable by any stretch of the imagination and our goal in fedora 27 and 28 Is really to have this become be put into shape such that we would retire our traditional legacy You know the one-size-fits-nobody DVD and Go fully into this boltron inspired world There's a lot left to be done with that We need a lot of composed pieces. I think we need We've discovered that there are a few bits and pieces of the modularity Like the module metadata that still need to be updated to make sure that we have all the information We need to do things like set up end of life and figure out which things are conflicting with other things but I Think the door 28 is a very realistic Date for that. I think that by the time we I'm standing here at next year's flock I think we will have Hopefully switched the server over entirely into being a modularized. Oh, yes All right, that is pretty much the presentation. I had prepared so This is a good time for questions or suggestions on how we might actually accomplish these crazy ideas and go Is our question there? So the question I'm going to rephrase the question So I think the real question in there is how does this differ from the alternative system? and The alternative system is really only designed to handle executables It's really only designed to hand to take a couple of things that Serve more or less exactly the same functions that have they take the same inputs and produce similar outputs the modularity initiative is Quite a lot more complicated than that. It's meant to be able to say My application requires Python 3.6 Or actually 3.6 is the standard one, but my application Doesn't work because they made a backwards incompatible change. I must have Python 3.5 That's a much much larger spectrum of changes than just Swapping out an executable like send mail for XM or what have you Is that a sufficient answer or do you have a follow-up question there Well, that's a bad. I'm gonna try to restate that and then disagree with it a little bit, but right, so what Steven Smoojin was saying is that With alternatives if you swap an alternative the entire system sees that thing whereas with modularity Only this portion of it would see that thing and then the rest of the system would have it default that is Not true In the case of modularity That's okay What we are focusing on I mean that that is an eventual goal, but what we are focusing on right now is parallel availability not parallel installable In cases of things like Python, that's kind of a special case where yes You can do that, but we are trying to solve the general problem first where you There are plenty of things that for which you can't actually have them coexist Sorry So would you if you're gonna go on do you mind if I just hand you the mic so I can get this on the recording So what I tried to tell is an Example here would be a factory that produces similar, but not the same products. Let's say cars Which What all laptops? Yeah, you you customize it according to maybe not to down to a single order, but to different product lines where Still keeping the same way of assembling them on the conveyor here modules would represent different type of components, but within each Similar module you would have enough differences that you would want to Capture at the moment where you create this model But then the conveyor stays the same whether you take Module a or module B that represents your web server Regardless of what's inside as long as they Consistent in expectations from other modules that would use these so in the end You would get an image for example if that's Docker or If that's installer image, you would get the same image with certain things tuned up. Maybe that's just Question of tuning up configuration files, maybe adding some Steps that only activated when you run this image first time But from the conveyor point of view all those modules are interchangeable Yeah, I think that's actually a pretty good analogy Yeah, but this is only a first step. So effectively right now in Fedora Project as a whole only Fedora infra and certain people are capable to Change what on the conveyor can be built as Fedora image We have alternative images and right so soon. So what we have the modularity Concept at least the goal would be that every Fedora contributor or user of Fedora contributed Infrastructure would be able to build up their own conveyor with Enough configuration changes there that it suits for their use Depending on whether this use is usable for others. I mean helpful to Solve others problem These modules might be might be published in somewhere, right, but it also Gives you ability to have People projects or companies doing enough tuning in their own versions of those modules yet Not spreading out work on the actual infrastructure that combines these modules together, right? Another point to make it to bring up that's related is that What will what will probably happen is we'll probably have a Modular a small set of modules that will effectively be the platform that we still release on you know every six months type of cycle and then individual then the modules that go on top that Will likely be it will have arbitrary versioning. So we'll have things like here's the Node JS 8 stream And here's the Python 3.6 stream and within these streams you will get all all updates that are available in those streams But you won't ever you know you won't have the classic Fedora problem of okay I go to Fedora 28 and all of a sudden I have Python 3.7 and half of my stuff doesn't work anymore You'll be able to stay on that until it's until it's a previously stated end of life Which is up to the package or to say upfront. I'm gonna I'm I'm willing to maintain this for two years or three years rather than six months or 13 months You know rather than 13 months in the Fedora schedule So it'll be so yeah, you'll be able to Will be able to construct systems that you can swap out things like the base to get the newer kernels and what that and whatnot But your but your software stack that a complete that comprises your application that you care about Will remain stable one moment to pass the mic and I just wanted to add one more point that It is very similar to alternatives. It's also very similar to groups. It's also very similar to meta packages It's also very similar to like Python and similar to software questions Basically that a lot of the point of modularity is also to make the concept of first-class citizen of the US So instead of alternatives, which is kind of like an add-on and it solves one part of the use case problem It's always one symptom right and software questions and solves a different set of symptoms the idea was that All right, let's step back a bit and stop trying to solve all the symptoms and instead say let's try to solve the problem and Then you know and then it enables things like you described it enables potentially parallel installability down the road or Parallel ability or it enables containers, but the idea is it's not It's not meant to be kind of the solution in and of itself as much as to say Let's go fix the actual problem Which are causing all these symptoms which are then in turn being fixed. Okay. All right So we are actually at time and I don't want to I don't want to take up the next time slots available time so Thank you everyone for participating. I'll be at the back of the room if anybody wants to continue this discussion, but Unfortunately, I do have to stop