 Okay, folks, we'll start chortling, if you see an empty seat beside you towards the center, please move so that the newcomers can squeeze in. Again, if you can see a free seat next to you towards the center, please move. I can see one there, one there, one here. Good morning, Rachel. Thank you very much for your cooperation. Excellent. Okay, I think we can start our next talk. The next talk is federal server expanding through our galaxy, presented by Steven Gallagher, who is a long-term community member, Dora community member and participant in multiple different open source projects. And general purpose troublemaker. Good morning, and thank you everyone who decided to come here instead of having lunch. Okay, that sounded funnier in my head. So, a number of years ago now, at Red Hat, a group of product managers went and performed what we call a gap analysis, where we look at all the things that our competitors were doing, and figure out what are the things that they are doing better than we are, and how can we improve on that, and how can we make life easier for our customers? Of course. Sorry, I'm a bit under the weather. So one of the things that we took a look at was, of course, for both rel and Linux in general, our primary competitor in the server space is of course Microsoft. It used to be Unix, but we won. So the next big move we had to make is how do we position Linux in a world that is, you know, at the time I think it was 15% Linux and 85% Windows. So one of the things that happened was that the product managers went and they asked customers and non-customers, you know, what were the reasons that you were, what were the reasons that you didn't adopt Linux, or what were the reasons that you didn't adopt more of Linux? So one of the big things that came up was, customers would tell us at Red Hat, well, it's too expensive to hire Linux experts, and we'd look at that and say, that's an answer to a different question. The real problem that they had was that the set of available people that could manage Linux was very small because Linux wasn't very manageable. So we spent some time looking at different ways that Microsoft and other companies made Linux more accessible to people so that it required less training to get at least an entry level administrator up and running. So one of the things we took a look at was a program called Microsoft Server Manager. When you boot up a Windows Server fresh after installation, you get a login prompt, and then as soon as you log in, you get this screen. This screen immediately tells you, hey, you've got a Windows Server. Here's a bunch of stuff you might want to do with it, and then it gives you a series of click-throughs on how to actually set those things up. You don't have to have three certifications at a PhD to set up a Windows Server. However, when you installed, historically, when you installed a Linux server, be it Rel or Fedora, this is what you saw when you log in. Now, I don't know about you, but that seems to me like it's less welcoming. So, okay, so if you were a user, and this is your first experience with Linux, what would your next action be? Okay, well, okay, that's a bad example. I probably should have pulled up Rel, because Rel doesn't have that, but that is jumping ahead, but panic. Or maybe if you're feeling particularly clever, you might type help. It depends on the distribution. I mean, a lot of them don't, really. But in any case, this is what you get with, if you just type help into a freshly installed Linux server. I've been using Linux for a long time, and even I don't find that helpful. Not in any meaningful way. This very clearly identifies a place where it is hard to get people started on Fedora and on Rel. They have absolutely no idea where to go once they have installed onto this disk. And I know if you're using a desktop, you might have a live image, and so that's a little more approachable. But if you wanted to actually set up a web server or set up a domain controller or a DNS server, this does not help you do that. At all. So, what are we going to do to improve on that? And what have we done to improve on that? The first step towards this was, of course, we needed to, and Adam alluded to this when he cheated earlier. The first step to this was, we needed to have a more welcoming interface. So, what we did was we built Cockpit, which is now installed by default on all Fedora servers, and is available on all Rails servers now. Cockpit is really, really cool. It is definitely nicer looking, first of all, than server manager. It can do basically, at this point, it can do very nearly anything, as we might have done in a GNOME session on previous versions of Fedora. You can use it to manage your network configuration. You can use it to set up and partition storage. You can use it to, in a limited way, you can use it to set up users now. There's another one I wanted to call out. Oh, of course. You can manage Docker containers with it. You can access the Docker registry around containers and just start stuff up. That, and it's approachable. If you look at the screen, it's pretty clear what each button does. It's pretty clear, if I want to set up a rate on my server, I'll hit the storage button, and I will then create a rate array, and it will walk you through the entire process. This is a huge step forward. It's still a little less discoverable than Server Manager, as we saw. When you log in, you still have, the best you have is a link on the login page, but at the same time, it's becoming standard. People now know that port 9090 exists, and that that is the maintenance port for a headless Fedora server. Okay, so I had a page on the networking stuff, which is complicated stuff to set up in general. If you're using, five years ago, if you wanted to set up a bonded network connection with Network Manager, I don't even know what to tell you. I would just advise you not to do it. Two years ago, if you wanted to set up a bonded network connection on Network Manager, you would use NMCLI, which was a huge improvement. It was still hard, even for an experienced administrator, but it was a lot easier. If you wanted to set up a bonded network connection on a Fedora server or a REL server today, this is how I would tell you to do it, because it will take almost no effort, and it will perform extremely well. So Cockpit has been a major, major piece of how we have improved the, at least initial experience for Linux, and it's providing a way that we can start telling people, yeah, it isn't necessarily the entire domain of the really long bearded folk. It really is approachable to just about anyone now. So the next step we wanted to do, this is great for basic system functionality, it's great for network management, it's great for storage management, but it doesn't help you actually, yet, deploy real services outside of some limited capability with Docker that has improved that, but it still requires you to know what you're looking for and know how to configure it. So we had a few false starts implementing what we were calling server roles, which is a general concept that what we want to be able to do is, in Cockpit, be able to hit a button and say, I want my machine or that machine to become a domain controller, and I want that machine to become an NFS share server, and this one to be a Samba share server. So our first pass at this was a service called RollKit. This was something that a few of us put together, it was a Python service that basically all it did was provide a common API for taking in answer file and turning it into whatever was necessary to actually install a complicated system like free IPA. For the six or seven people that ever noticed it was there, they found it very useful, but ultimately it did not achieve any adoption, got backburnered and is functionally, it's on life support, it's still there in Fedora, it still works, but nobody's actively working on it. It was beneficial in that it was our first step at trying to have a converged API that allowed us to manage a whole bunch of different, well, it wasn't our first try at a converged API, but it was our first real attempt at having a unified installer of sorts for Linux, and it was relatively simple. It was a trivial D-Bus API, the answer file was a very, very simple JSON. The basic policies behind it were that it must be possible to install with no arguments, which included, even with free IPA, we would just auto-detect the domain and give you a random password. But ultimately, as you can see, we had a bunch of problems with it. It had fairly heavy dependencies. It was Python, it depended very tightly on Network Manager, it depended very tightly on Firewall D and on basically the entire Python stack. It was forward-looking, but it was really not possible to... Oh, sorry, I mentioned... It was also reliant on system D, which meant that basically it could not possibly have been backported to anything earlier than, say, REL7. It would have been interesting going forward, but we also needed things that would be able to work on existing systems. We can't always assume that everybody's going to upgrade to the next thing. In my job work, I still have people, when I occasionally visit customers, who are still trying to convince me to tell my management to push out a patch for REL4. So we needed something better than that. So how do we get there? What is our better choice? Well, the other part of that, of course, was that we had no client support. We had a CLI that was basically intended for testing. We had always intended for it to be powered by Cockpit, but the API was never exactly what Cockpit wanted, and really what we wanted out of it was something that looked more like this. We wanted to be able to go to another simple tab in Cockpit. This is a mock-up of work that's being done right now to build an NFS-shared service in Cockpit. We want to be able to just say, pick this directory, make it available to these people and these machines, and that's that. That is actually much more complicated than it sounds to do it yourself on a bare system. But we have all the technologies out there to make this effectively automatable with very little human interaction, asking a couple of simple questions. So why haven't we been doing that? And again, the problem is just, well, first of all, we didn't get there yet, second of all, we didn't have any kind of a unified API for it. So the NFS server is the first one that we're really using as a proof of concept of a new approach that is going to be driven from Cockpit first. Before we do any kind of development under the hood, the idea is we're going to be user-focused. We're going to have Cockpit's designer, Andreas, and collaborating with other teams to figure out what does our user experience need to look like, and we're going to build a role around that. NFS server is the first. We're prototyping that. We expect to have that available for Fedora 26 from top to bottom. Coming down the line, we are heavily invested in producing a domain controller role based on free IPA. And I hope Demetri is listening very carefully because that is very important to us. I'm sorry? Well, we'll talk about it afterwards. Anyway, other popular roles that have been requested by our users, we want a Samba share role, which will be very similar to the NFS one. I expect that the interface will be almost identical. People want a system deployment. They want to be able to take a machine and say, this machine is now a server that will pixie boot an install of my preferred layout. And of course, no collection would be complete without a database server. So, how are we doing this without roll kit? Well, we had to replace it. We wanted to find something that we could do that was similar in purpose to roll kit, something that would provide us a common API that we could use to talk to a variety of different systems. And we wanted to produce something, or we wanted to use something that also might work on a variety of different operating systems, be it operating system version, or completely different families, things like Ubuntu and BSD perhaps. So, we switched to Ansible. At this point, what we are doing is we are working with the Ansible teams and their upstream, and we are developing a series of new modules, Ansible modules that will be cross version, cross distribution compatible. They will take the same YAML file, do whatever is necessary on each different version so that we can maintain a single interface that is made public. And then we are going to consume that with cockpit. We are going to have that nice cockpit UI that I showed you. After it asks you its questions, it is going to essentially build an Ansible playbook under the hood and offer you the opportunity to either download it or execute it immediately. And that will make the machine that you are talking to become that configuration. And the best part about that is that it is going to work. We are focusing on Fedora 26 and REL7 first, but there is absolutely nothing there that could not potentially be back ported. You could take that output file from cockpit and presumably you could run it against REL6. You might even be able to run it against REL5. And you would get an NFS server with that configuration out of it. So, the commonalities is important because we can use Ansible as a tool that doesn't require all of our users to learn an individual tool every time they want to change something. You want an NFS server? Yeah, write an YAML file. You want an IPA domain controller? Just a slightly longer YAML file. This will give us a lot of... It is very easy to develop an Ansible script and as long as we continue developing these modules and building cockpit UIs for them, I think we are going to be driving towards a de facto standard on how you would manage a system with a common API. Something that we tried once upon a time with RollKit and we tried even earlier than that with OpenLMI. I think we can actually succeed here because the ease of use makes it so approachable that our users and our customers won't need advanced degrees to figure it out. So, where do we go from here? How do we keep it growing? How do we keep it advancing? And I think we need to maintain communication with our customers, our users, and our developers especially. And one of the things that's moving to Ansible gains us is Ansible has a tool called Ansible Galaxy, which is a repository of user-submitted roles and playbooks for doing common tasks. What I envision down the line is that we expand Ansible Galaxy and embed conversations with the Ansible folks such that you build Ansible roles that are designed as Fedora slash rel server roles that contain not just the playbook but will also eventually contain a module for Cockpit to go along with it such that we should be able to down the line use Ansible Galaxy as a way to have third parties developing their own easy-to-use plugins for Cockpit so you could have SAP builds an Ansible role that will deploy their server giving you the nice installer interface in Cockpit or Steam or any other third party or open source project that wants its face in the system can provide that and it will require very little effort on their part to do so. So I think that's a longer term goal. That's something that I'm looking at and I think we're looking at in more like the two- to three-year range. The initial set of roles that I discussed before the NFS server, the Samba server, the domain controller those we are... the NFS server we intend to have for Fedora 26 I am very hopeful that we can have at least one if not two more of those done in time for Fedora 27. I would very much like domain controller for those two. Back to your question earlier. So that is basically where we're going. I talked a lot faster than I intended to so I've actually reached my questions page. So let's have some questions and then afterwards maybe you guys can go to lunch. Not exclusively. Sorry, the question was that Cockpit, the question I was asking is Cockpit more than just an interface to local D-Bus APIs? And yes, it can access theoretically any standard interface on a system be it D-Bus, be it Arrest API and in this case we are going to be standardizing on Ansible as that API. I'm just going to reset the question. The question was whether Cockpit was going to have to call something like a D-Bus or other interface to invoke Ansible or if it was capable of invoking Ansible directly. And I'll let the Cockpit experts over here answer. There is no need to use it. Is it going to use it directly? Yes. So just for the air recording Cockpit is going to use Ansible directly. I was a little big on that myself. I'm kind of on the side. Basically, you have to talk to the installer. Because I know installer in Fedora and in Threl it actually supports extensions that you can write yourself and just put them to the right directory and it will show up on all the oven spoke screens. And then you can actually and then the initial setup or the initial setup is actually the same thing. It's basically installer after reboot. It would be able to install some of that stuff using Kickstarter or even directly doing the installation. You wouldn't have to do the second step. So the question was have we talked to the installer team about doing this as a plug-in to the extension to Anaconda where you could then just do some of this setup as part of the installation path instead of doing it as a secondary. There are a couple of problems with that. The first of which is you may or may not actually have on the install media all of the packages you need to deploy any possible role. So, okay, let's say maybe we're only doing this with net installs. The other issue with that is, of course, you may not always know up front what system you want. There are lots and lots of people who deploy a system by building it once on a VM and copying that VM out and then configuring the result. So no matter what, we always need to have some way of deploying it on a machine that has been installed. So while that might become a nice to have down the line, it's not an urgent feature at the moment because it's very nice to be able to update that later. I don't see that I understand that... So you take the Ansible script output from Cockpit and you can automate that. Cockpit is just generating essentially generating a YAML file and then it executes it for you. If you can take that YAML file, plug it into your Ansible tower and use it to provision a thousand machines. Yes, but I'm not sure what the exact UI is going to look like for that yet. That's still being designed. Well, I mean, as mentioned before, in some cases we want to take a page out of what Microsoft is doing when it's doing something well and if there's any one thing that Microsoft has done well in recent memory, it's the fact that all of their graphical tools do have all their actual work done by PowerShell. The graphical tool will walk you through the wizard, it gets everything ready to go and then at the very end you can either do it or take that PowerShell script. That is actually really powerful and administrators love having that available to them and if we can do the same thing with Ansible, we really should. I'm sorry, can you speak up just a bit? I can't quite hear you. Can you speak up a little? So I'm going to attempt to rephrase the question and see if I got it right. That the concern is by having a playbook generated by a UI and then exported that while that might be handy that oftentimes it will end up generating something that doesn't really match that may have what you want and a bunch of ancillary stuff that you don't necessarily want. I would personally argue that that is exactly the right moment to use the export button because before you then execute on it you can simply make whatever manual modifications you want it to. If you could look at it and say this UI didn't make exactly what I needed, there's absolutely nothing stopping you from modifying that YAML file and then running it in Ansible yourself. Again, the question here is at that point now you have to understand what's inside and know what to change. What we are offering essentially on the module and the Ansible side is here's an interface that you can use however you want it. On the cockpit side we're saying here's an interface you can use if you don't know what you're doing yet. Here's a good place to get started. Here's how you set up your very first NFS server. Down the line as you learn more and you decide okay maybe this isn't doing exactly what I want it to do now you have more information and you can take what you've already learned and then modify that move to using Ansible scripts directly instead of using the UI for that purpose. Does that answer your question? The question was excuse me the question was in Fedora 26 we are planning to produce a prototype from the modularity effort that we're calling Boltron, Project Boltron that is built out of the base runtime module and a few add-on modules. The question is whether or not we're working with Cockpit to produce a UI to put those modules together. Yeah. The short answer is right now no because we don't know what that's going to look like yet. It may be that in the first pass modules besides those necessary to produce the installed system may just be containers and then Cockpit's existing container management UI is sufficient. It depends on what we end up producing as output artifacts of modules because modules themselves are not a packaging format. They are a metadata format to produce artifacts that are maybe a yum repo and maybe a container, maybe a software collection things like that. So we don't have a unified view of what that looks like yet to tell Cockpit or to ask Cockpit to write a UI to manage it. So once we get that more in order and I think that will happen next three or four months we'll see where that leads us. Does that answer your question? Anyone else? Dominic? The question was right now from what we've seen how much effort is there to implement a Cockpit module for a role? Yeah, of course it's always going to depend on the role. All right. So the quick answer to the question would be attend the Cockpit Hackfest where they will walk you through the process of creating a new component in Cockpit. Yeah. From my personal experience it's not terribly difficult to make new UI elements for Cockpit. I think a lot of the harder part is going to be the design of the interface underneath that Cockpit is going to call. And that's going to be just a matter of doing enough research to figure out what are the best case or what are the best effort defaults to have for these roles. And to that comment the most amazing part about it is that every one of those new pieces is going to be backtesting. Which is a core piece of Cockpit upstream and one of the reasons why it has been so successful and has taken off the way it has is that it actually just keeps working on so many other things we throw into Fedora. Just keeps going. There was a question from this side of the room earlier. Gens? We're not here to question you. We're going to go to Ansible Tower. All right. So the question is to what extent Ansible Tower is doing here? 100%. If you have an Ansible Tower and you want to interact with these same modules by all means, do so. I encourage it wholeheartedly. The fact of the matter is that by the time you have an Ansible Tower we are well into the you already know what you're doing category. And that's not specifically the audience that we're trying to address here. We are making sure that all of the stuff that we do is fully compatible with Ansible Tower because we don't want to you have to relearn anything. How do we get into being the tiniest to something to being the biggest to something? We're missing the perfect way to be the tiniest to something you throw. And that's what this is supposed to provide, right? Exactly right. I'm going to try to repeat that because that was well phrased. Yes. Okay. So the question is we're talking about the I think he used the phrase Rack Monkey. They'll come in they'll hook up the the keyboard and mouse and they'll make a couple of changes on a few individual machines. And then what he's asking is are you envisioning them being able to then add their own roles to this? I'm not necessarily certain that it will be the same person. In fact, I'm pretty sure it won't be. But today could a user grab this extended with their own recipes and push it into production in their systems and the answer today is no. The answer sometime down the line with that integration that I want to do with Ansible Galaxy the answer should be a resounding yes. Further questions? So the question was we've talked about an export feature for these YAML files for these Ansible playbooks but do we envision an import feature for those same ones so that you can export it and import it on the other machines? I don't believe we have a direct we have a plan for that today simply because I mean we're designing the UIs to be as trivial as possible you should be able if all you're getting from that output is what you got from the UI it should be almost the same amount of effort to just duplicate it as it would be to import. The purpose of the export really is for those somewhat more advanced users who want to take that and start manually manipulating them and since we don't want to try and guarantee that that will necessarily import cleanly once they've made we'll have them just say run Ansible locally and target the machine. So the question is on server manager it's possible to use a single machine to also connect to and manage other Windows server machines and using the same tools and will cockpit be able to do that? Right now we are focusing on the individual machine case Cockpit is probably a hammer for that screw in terms of doing it at scale there's kind of a gray area on the 5-10 machines do you want to manage one rack or one room with cockpit? I think there's some question there it's not on the immediate roadmap but we'll see where we are in two years. Is there a question back there? Anybody else? You look inquisitive I seem to have used up less than my time but go have lunch. Thank you for coming. This is 4.5 different walls but the extra making is down the road we have 50. You don't want to have 2.3 or a minimum height of this you want to come at the end of the road and you start with 3 and I'm interested in that first the main control so go down I don't want to define the UI these are the three things I'm interested in and it's sort of installed and clear and then it is added so that I can click. What do I offer at all for the system? The last time I mentioned there was the Galaxy API for the system and then you put a button to install the system and then you put a button to install the system and there was a confusion that was sort of I didn't want to there was a confusion about really who both work and installs work because as far as I understand it still needs to have some interface to the Ansible Playbook and interact with Ansible so it needs to port even if it is going directly it's like both codes to make a pair it shouldn't be something that you can do on your own so it can't be any it's not it's not so I have to go out UI is just a gesture and the right gesture is called an API and there is something running on the backend that takes my input and I provide it and does an action so this is a cockpit module a cockpit plug that does the work related to a specific work so it is a separate piece of code as well as your JavaScript UI that reflects the parameters and reflects the steps it doesn't do anything else and it calls then Ansible with specific parameters as playbook and arguments so it goes and sends and does this thing under Ansible there is Ansible in it that does the actual operation in Material 2 which is vital so you really have several layers of JavaScript with a cockpit module which I don't know what it is written in I assume it is then it is Ansible Ansible 2 with Ansible playbooks and words Ansible module under and then the actual command line and the capabilities of the IPM we need to actually do to install this so this is the first step and you can slice this in different ways it is like right ok like now in Italian you can use this to close down the storage and it will already have that close to it and it does not prove to the module that for example it won't make that much of a difference it is the same as calling it with that module but it may have to make a difference I think we always want you to say that between the type of UI the actual experience where you want to connect it between the two types and I assume there is conflict between the module and the module you want to take it on the class and then type it it has to type it in your browser that is running on the system on that system it is still working so on the other side it has javascript, gv, gs so you have a javascript and you have a picture of kx so you are logged in as an user so from javascript actually is that what do you want to say? so there is this thing in between we don't have that other abstraction it is just called ansible is the API ansible is the tool you want to use that is what we are talking about if you want there is not another abstraction there between the ansible and exible so that wasn't clear that there was nothing else just javascript I mean there is basically a transport link since you are connected to the it is all built in a sort of power shell you are really well you have that you don't really have to run the command it just keeps the same before you use it but you already have ccd we have to be able to have it too we have columns we have functions that make it easy to run the command there is something in there to change the transport link that is what it is do you deserve a new shell? I mean they also have the shell you can get a full loan shell if you are talking about it no I know the terminal the terminal so in your opinion who is responsible for writing are we downstairs? are we downstairs? I'm sorry? are we downstairs? no so yeah so what is the bathroom can you just write yeah alright sounds good so do you have access to the slides? there are some free opinions so could you open you give me access to those slides? I just need to present it and I can it for some reason probably needs anything yeah I don't know why oh no it's just messed up okay because there's no play button right it's just real okay I'll request it right now thanks can you read it? okay ciao what? sorry so yeah so thank you it's great you have a great idea No, I don't know, I don't know anything about it. Thank you. So, here I have this. I've changed a lot of settings, and here, the display is here. Do we have a Mac on? No. I'm glad to see it. Do you have a Mac on? I don't know. Do you have a Mac on? I don't know. Do you have a Mac on? I don't know. Do you have a Mac on? Do you have a Mac on? I don't know. Do you have a Mac on? I don't know. Thank you. So, I need to make this primary for some reason. I have to say this, so I need to take a moment. I don't want to break it now, Do you want to introduce Adam? Do you want to introduce ourselves or do you want him to introduce you? Adam. Don't ask me to be quiet. Okay. You will do it. Okay. That sounds good. Okay, now it's... What the hell? Why are you doing this to me? So... You're doing this again, so I have to... No? No? Okay. It's okay. He doesn't mind. It's just great. And I still have to put it there. You are Ozu, the part of the modulality, right? Yup. Oh, it was. I had to do it now. Yeah. Okay. Okay, yeah. There are some... I'm just fighting with the displays because it's like shitty. I want something smaller. Oh, just... Oh, this shit. Yeah, that's fine. Oh, my God. So... All right. All right. It's just completely broken after some reason. I don't know why, but it's broken. I mean, we want to use your laptop or something. Maybe... No, no, no. I'm just stupid. I'm just stupid. It needs to be two, two. Yeah. Okay, that looks good. Yeah, this is fine. That's what I wanted to do. And also... That's great. All right. No. I don't know. Or a few Macs. Can you get Macs minus the window? No, I can't. This is just shit. Can you get your laptop out, please? Yeah. Maybe we can use yours. Because this is just fucked up. Like, I would have to restart the machine because I'm just... I don't know. Yeah, sure. Can you close all this? Yeah, that's fucked up. What's your deck? Oh, deck dash one. Oh, yeah. Probably. That's... Some higher, remember? Oh, great. Okay, do you have HDMI or VGA? VGA. All right, so let's just... Let's use that shit. Thanks. Do you have enough battery? Like, can it... Can it... No, you need to plug it. I don't like plug-in. What's that? I don't like plug-in. I don't like plug-in. I don't like plug-in. I don't like plug-in. I don't like plug-in. I don't like plug-in. I don't like plug-in. Okay, that's great. Yeah, put yours in the back. VGA? VGA? No, it's fine. I just need to play it. Is this my way? Yeah, that's your deck. And then the other side. Why there's no editing? Like... Why is it fucked up already?