 So, let's go ahead and get started. Next slide please. So, what is Ansible? I thought I'd do a real quick little thing here talking about Ansible in the various parts of it. Ansible is an agentless provisioning configuration management and deployment tool. And when we talk about agentless, we mean you don't have to run a client. It manages things by SSHing over to them and then running its code or whatever you tell it to do at that point. So, you can use it for provisioning new things. You can use it for configuring them. You can use it for orchestrating deployments. All kinds of things. It's a very flexible tool and I think that's one of the reasons why it's been so popular. That and that it's pretty simple. So, next slide please. Some more concepts. Control node is where Ansible runs from. It's usually the place that you have your playbook code and roles and things like that. I'll talk a little later. The REL guys are working on something to use containers for your control nodes, which is pretty cool. But right now, control node is typically a REL, Fedora, etc., Linux box and that SSH is to the other things that you're controlling and runs your code. Playbooks are YAML files with just a list of tasks and a list of hosts to run those tasks on. They're pretty simple. You can do complicated things. You can do simple things. Roles are kind of a conceptual unit of tasks. So playbooks can include roles. A task might be like start the web server, whereas a role might be deploy our documentation server or something like that. So roles are more specific, usually more opinionated and they do a complex series of things that are a conceptual unit. Next slide. So Ansible has a few more things. Plugins can change the Ansible behavior. There's all kinds of different plugins. There's connection plugins that you can get that change you from using SSH to log in other machines to WinRM, the Windows management thing. There's some that talk to routers, some that talk to just all sorts of things for connections. There's also plugins that change how things look, how the output looks, how the playbooks are parsed, how your inventory is parsed, all kinds of things. Modules are a discrete code that can be called for a playbook or command line. A module would typically be things like a system CTL module. So it knows how to start, stop things, basically call those particular things. You might have a module that's authorized keys that parses the SSH authorized keys format and knows how to write entries or read entries or manipulate them. So modules are just sort of a nice way to reuse that sort of generic code in your playbooks. Ansible has a thing called Galaxy, which you can think of like it's CPAN or the like or PerlPiePie. So basically it's contributed roles and reusable things from the community. And Galaxy has a lot of stuff on it. There's just all kinds of things there that you can use. A couple of years ago Ansible came out with a thing called collections, which is basically a distribution format for Ansible content. So a collection contains one or more or zero or more of the following things that we just talked about. Modules, roles, connection plugins, whatever, you can put it in a collection and Ansible knows how to move those collections around, it knows how to update them, it knows how to install them, remove them, et cetera, et cetera. So it's just like their packaging format for Ansible content. Next slide. So a little bit of history here with Ansible. It became insanely popular for all the reasons, simple, it was easy to write. It was declarative, it didn't need agents. All kinds of things that people were looking for. But it sort of became a victim of its own success because there was just the Ansible package and it had all the modules, it had all the associated stuff. There was Ansible, that was it. So this was all in one GitHub repo. It was growing kind of without bound over time and the core developers just could not keep up with this. They tried some automation techniques but even there, a small minor change in a particular module that not very many people use is not going to get that much priority and the core developers don't get around to merging it and the thing sits around for a while and people get upset. Also there was a problem with cadence. There might be a module that updates and there's a really important thing and they need to get this module update out but there's only the one release cadence. There's Ansible. There's the whole thing. So they have to laboriously collect everything up for a release and then do a release and the schedules could not match up. So they had a lot of problems with that. Next slide. So they needed to make some changes and the changes they made in the last couple of years are kind of to get them out of this hole that they were in. This popularity hole, popularity is great and you want to keep that momentum but you don't want to be behind an annoying people and not moving forward. So what they did is they split the engine out. So the engine becomes Ansible core. It has just a few things in it. It's got a few basic connection plugins. It has the engine that actually handles the base part of Ansible and they split that out from basically all the collections that had all the other stuff, the modules, the things that people don't use as much or specialized collections, etc. And because they had collections now, they could tell people, okay, you need to have a collection of this stuff. We're not going to maintain it in one place. We're going to have a collection of it and you maintain it. So say you're like Cisco and you want to maintain Ansible roles or modules that manage your routers, you can then directly contribute and work on that thing and have power over it and when it releases and when you get fixes in it and you care about it and you can test it and you have the hardware and etc. So this ends up accelerating all those areas which were not getting a whole lot of power before because there was the bottleneck of the one package. And with this model, the engine and the collections can change as they need to. There still is, of course, dependency there. You want to make sure your collections work with that particular engine. If the engine makes some radical change that needs the collections to change, you need the dependency there, but you can make that change and you can develop at the same pace. And it's really important that the maintainers of these collections are people who use them. And a lot of the Ansible modules were specific hardware or things that a core developer wouldn't even have access to that hardware to tell that it works still after the change or not be very aware of how that thing works so they might merge something that doesn't work very well with it. So it really works out a lot better in this case. Next slide. So what about the users who want everything? The batteries included method like we had before with one big Ansible package. So they wanted to still handle this case because one of the clear things that was communicated to people in the past was that you just had to install Ansible and it's batteries included. You don't need to install a bunch of stuff and it just works. So what they did is they turned Ansible into a meta collection. So it is actually a collection of other collections. And those collections have agreed to release on the same schedule and they've agreed to certain other restrictions. They've agreed that they'll handle security bugs a certain way. They agree that their changelogs are formatted in a certain way, et cetera. Right now I think it's about 120 or 130 collections in there. There's just really a lot, a lot more than there was in the monolithic Ansible package in the past. So that becomes the meta collection and then Ansible Core is the engine. So the Ansible collection has all those collections in it and it requires Ansible Core. So if you just install Ansible you have the whole thing. So this handles a very important case of people who bought a smaller footprint. If you want to just install Ansible Core the engine and you know you're only going to use these five collections, you can install those specific collections using Ansible, of course. No problem and you don't have to install the meta collection and you can just save yourself the space for that. Next slide. So what about Apple in this whole change? Apple 7 is going to keep Ansible Classic, I call it. That's the current 2.9 sort of monolithic old Ansible. And that's going to end of life somewhere near the end of next month. It's just ending life upstream. They're not going to maintain it any further. So that's kind of the end of the line for Apple 7. You're going to probably want to move your control host to something different. There's a lot of choices there, including some that I'll bring up in the next few slides. For 8.6 and 9.0 Ansible Core is in rel now. It is shipping in actual rel. They are shipping it in order to leverage Linux system roles. If anyone here has not heard of that. Linux system roles is an Ansible collection that handles basic Linux system administration type things. So configuring your network, configuring your storage, configuring encrypted devices, all that kind of stuff. It's really handy and it's really nice. So basically they're shipping Ansible Core to support that. But you can certainly use Ansible Core for whatever you wish to from there. And we're going to add the Ansible Meta Collection to Apple 8.9 very soon. I think we already have branch requests out. My co-maintainers have already done that. So soon or as soon as that lands, you'll be able to install Ansible, get the Meta Collection and the engine and have a similar experience to what we have in Fedora. Yes, as I was pointing out, Ansible Core, it is actually supported by rel for running Linux system roles. If you run Ansible Core and rel doing something else, you're not going to get support from rel for that use case. Next slide. So I thought I'd mention a couple of future items here. Rel is already using a thing called Ansible Execution Environments, which folks might want to look at. It basically replaces your control host with a container that's running the universal base image from rel and a known specific set of configurations. This is really nice, especially if you're wanting to run Ansible from OpenShift or you don't want to particularly dedicate a control host to this, you would rather run it in a container. Also I believe Ansible Power is going to be using these as well. So that's a nice way to run your control host. And there's been some talk about retiring the Ansible Meta Collection at some point a number of years down the road, maybe. There are still, I think, a number of users who want that, all collections included ease of use where they don't have to worry about what they install and so forth. But there will be a lot of discussion about that, and certainly if you have an opinion on it, you can chime right on in. Next slide, please. Okay, questions. Boy, I don't see any in the Q&A. Yeah. Oh, yeah. There are. They just weren't loading. Yeah, these are, I think these are all the questions from the previous session. So I'll throw one in. One second. I can't hear you. Oh, no. Can anyone else hear me? Okay. Marie can hear me. Come on. Can you hear me? I hear you. Yes. I can hear you now. All right. Great. Anyway. So I'll go ahead and throw a question your way. So apart from the change in how the modules are collected, are there any other sort of big user-facing differences in Ansible 5 that people should be aware of? Not a whole lot. There is, well, there's a lot of behind-the-scenes stuff. The version of Python that's required is newer, which of course doesn't matter in Fedora, because we're already using the newest Python, but for RHEL it's using Python 3.8, which is the lowest requirement. But yeah, there's not a whole lot of change there so far. There's the playbooks that you have now in using in the old Ansible will, for the most part, run fine in Ansible 5. They've also, I probably should have mentioned this, they've also switched to semantic versioning for Ansible now. So if you have an Ansible 5.x, it's going to be compatible. And then when they do Ansible 6, there'll be a breaking change there, and you'll have to check your playbooks for deprecations and so forth and so on. But yeah, not a whole lot of big things for user-facing side of things. Newer collections, I suppose. So how much does Ansible upstream participate in Fedora, or is it basically they produce their version and then we package it up and use it? Well, yeah, it's been pretty much like that. I was maintaining Ansible for a long time, pretty much by myself. But now, lately, I've gotten some great co-maintainers, one of whom is in the chat, Maxwell. And also, we've had some help from upstream, one of the upstream community guys is now also packaging. He did the initial Ansible 5 packaging for Fedora, so he's been working on that. And Neil Gumpa helped us with the Ansible packaging package, which allows you to build collections in Fedora. So yeah, it's kind of a mix. They're not super involved in Fedora, but there is definitely still some involvement.