 Hello everyone. Tim, can we hear you? I hope so. Yes, excellent. All right, so everybody, this is the Ansible Community Meetup. I will hand over to Carol and Tim and they'll take it away. All right, Tim, do you have the slides? Oh, yes, sorry. I'm still getting set up here. Oh, well, let's see. How about, Carol, you do intros while I figure out what's happening here. Okay, so hi everyone. Welcome to the Ansible Community Meetup here at DevCon CZ 2022 Virtual Edition. We have Tim Abnoe and myself, Carol Chen, here as, you know, we're just here to guide and receive your questions. We'll start off with a short introduction about what we do in the community. And I see on chat, we also have Gondola Barker, who is the engineering manager in the community team who will help with some of the questions that you might have. So if I might interrupt for just a second, Carol and Tim, we have also posted two poll questions that Carol and Tim have supplied us with. So if everyone in the chat would like to visit the poll tab, you could see those. Thank you so much, Michael. So yes, if you click on the polls, there are two questions currently, and we'd like to find out where you are in the Ansible user or contributor journey, and which will help us perhaps frame the discussions and kind of anticipate your questions and then we can respond accordingly. So please respond to the poll questions when you get a chance. Thank you. Any luck, Tim? Almost. Almost there. So close. All right. This might be it. How's that? Yes, we see something. Yes. Okay. Sorry about that, folks who are just having some AV setup issues here, but we're through it. Okay, great. So let's see. I'm sorry. Well, I was working on my setup here. Did I need to intro myself? I didn't share. Yes, please. We haven't actually done the introduction. I just said welcome. Okay, great. I'll let you start then. Okay. Hi. My name is Carol Chen, and I'm part of the Ansible community team here at Red Hat. So we work mainly with the upstream Ansible community and to promote and collaborate with the community in the contributions, meetups, outreach events and so on. You can reach me at Carol at redhat.com or on most social channels with the ID Cybert on Twitter, liberalchats.rc, Cybert at matrix.org, and so on and so forth. Tim, over to you. Yes. So I'm Tim Ampel. I'm a product manager at Ansible. I'm also self-proclaimed evangelist of Ansible. I've been with the Ansible project for a very long time as a first contributor. I was a customer at one point, a consultant developer, and now product manager. So I've kind of seen Ansible from a lot of different sides. So that is me. So do we want to get into poll questions first so we know what our audience is like here? From the current responses, we have actually, if you go to the poll tab and you can see the results, we have quite a lot of people who have a lot of experience with Ansible, which is great to see. 40% with four or more years of usage experience, although there is about almost 20% with less than one year of experience as well. So, okay. And some people are new to Ansible. Welcome. We appreciate you joining us. And for those who have been using Ansible, we thank you for being part of the community for all this time. Well, that's good to know. Yes, likewise. Thanks all for being here. So what we have today is this is supposed to be a very interactive session, kind of a choose your own adventure, if you will. Kara and I have a few slides here to start off, to talk about some things in the community, just for general awareness. And then from there, we encourage you all to ask questions in the chat in the Q&A. And Kara and I will do our best to answer those. We can actually bring people on video feed to ask the questions as well. Oh, okay. Great. Yeah. The limit is 20. So, yeah. And also, perhaps some people in my team is here and they could join in and answer as well. Yes. Okay. So, yeah, just an announcement to chat. If you would like to join, just request to share your video. And I will add you to the discussion. And yeah, that's it. Okay. Oh, that's awesome. Seeing real faces. This is such a weird experience. Okay. So what I'm going to do here is just, I'm going to start a little bit and Kara and I are going to go back and forth on a few things. I just put this in here, not knowing ahead of time how new or experienced everyone would be. But I always like to come back to this because it's really the principles that Ansible has always been based on and continues to be based on. And the idea of creating something that is both powerful and simple and finding the balance between those two things and then more, you know, something that's really differentiated us is keeping things agentless so that there's that low overhead to getting started. There's a lot of flexibility and power that allows this architecture to do things like work with Edge or work with network devices and things like that where you cannot run, you don't have a more traditional operating system where you can install Python and all these other things or have a lot of processing power there. So, you know, these things I think have really created a really strong foundation for what Ansible was based on and why it's grown and has so many use cases and such wide adoption. I'll take this one, Carol, and then I think there's a couple coming up that you're better suited for here. So, I have a session, well, I have a session tomorrow where we can go more into depth. But right now what really defines Ansible, particularly in the community space, is the Ansible community package. And this is the open source batteries included distribution of Ansible. And this is something that Ansible was known for from the very beginning. The project always included all the content, the modules, the plugins, all in one distribution, didn't need a package manager, you installed Ansible, you got all these modules. It's something I'll talk about tomorrow. That was great. In the beginning, when I remember I got started, there's like 40, 50, 60 modules. About a year or two ago, I think we definitely passed 3,000 and we might have touched on 4,000 modules. So, it was getting quite large with all the different use cases and adoption that we were seeing out there. This now is what is out there for everyone to use that's just like that in that batteries included model. And this includes the Ansible core engine, the latest stable version, and then a whole lot of modules and plugins. Those modules and plugins are there's the core ones, the ones that you really can't use Ansible without, but then there's also hundreds and hundreds, actually probably thousands, I should say, of community supported Ansible collections of these modules and plugins that are added to the community package based on this inclusion policy. We have a link here and we'll be posting these slides shortly after we finish here. I'll be doing that. That's on me. But there's a whole community process for developers that create their own collections and want to contribute it to the community package to getting it included in the community package. This community package has a different versioning scheme than the ones that was traditionally known by Ansible. So before it used to be 2.7, 2.8, 2.9, the community packages move to semantic versioning because this community package is now different than the Ansible core engine. They're two separate projects and they have synchronized timelines for the most part, but they are independent. So they have their own different versioning and the community packages move to the semantic versioning scheme. So you've probably seen a 3.00 and a 4.00 and I believe we're up to 5.2.0. I think we're still at that .0. Yes, we are. 3.0 is expected next week. So yes, that's the latest. Oh, 5.3.0. Okay. So one thing to put out there that I know from talking to some people there's been some confusion is that separation now that there's the core, which is still in the 2.0, it's at 2.12, and then the community package, which has its own semantic versioning, and that's moving at like a 5.2, and like I said, like Carol just said, a 5.3 is coming. So the community team look to make a release approximately every six months, roughly speaking. Like I said, it is somewhat synchronized with how the core engine is making releases, and this package is available and released to PyPy. Other means pick it up later, but PyPy is where it goes out first, and that's sort of the official place for a release to drop. If you have more questions, we can answer them here, but if you want to read them later, there was a blog post made a little over a year ago, year and a half ago, that covers a lot of the questions, the answer of all the changes that went on in how Ansible is packaged for the community and distributed and the differences between the core project and the community package. All right. So with that, I will turn it over to Carol, something you're directly involved in. All right. Thanks, Tim. So as Tim has said, this change to collections over the past couple of years, there's definitely a lot of new things and new processes and just more information that we want to find a way to make sure that everybody has an easy way to keep up to date with all the different changes going on, new collections coming up and so on and so forth. So I think in April 2020, when everything was locked down and we couldn't have meetups and in-person events to share a lot of this information, we started the Bullhorn newsletter to share this information more broadly and easily to the community. So we started as like a once every two weeks thing and it went on quite regularly with content from not just our community team or Red Hat, but also actually a lot of the content is contributed by the community as well when they update their collections or they make some changes to some of the tools that they are using or even write a blog post about their setup, we share that in the newsletter. We want to promote all the activities that's going on, not just within the community team, but also in the broader community. And there's a subscribe link of course you'll get in the slides when we share it, but I'll also put it in chat, you can subscribe to it if you haven't already. And we are actually moving now to a weekly release for the newsletter because we are getting the momentum and you know there's just a lot going on like I said. And you can also check out the archives of the past 44 newslet. I think I released 43 issues. I just released 43 this morning so feel free to check it out. And there's also information on how to contribute news items if you have any to the bullhorn. So that's it, thanks. Next slide. Yes, I have to say I always open the bullhorn as soon as I see it in my inbox because it's the only way to keep up with there's just so much activity now in the community. So yeah, I really encourage people to subscribe to that. Real quick plug here, tomorrow there's another Ansible presentation. I think we'll probably end up covering a little bit of what's in that presentation here, just that's the way the ordering of these events went. But it's going to be tomorrow at 4.30 Central European time. And it's a half hour presentation on what's new and ahead for the Ansible community, particularly all the different projects that are out there. The ones a lot of people identify the Ansible core project as what Ansible is and now the Ansible community package. But there's a lot more projects going on out there that will help both developers and also just expand the Ansible ecosystem. So that's what I'll be covering in that presentation tomorrow. So mark your calendars and please stop by. Okay. So Carol, this is probably a good one for you. Do you want to go over some of these community resources we have? Yeah, sure. So the kind of main, I guess, portal page, if you will, links to more of these resources is on ansible.com slash community. You will get to see the GitHub repost, the mailing lists. I was just updating the links to the matrix rooms that we are having, which is one of the major changes that we did last year was to support both matrix and IRC for our real time communications with the community. We have had people comment that there is some kind of a learning curve or a barrier using IRC for a lot of newcomers. So we moved to matrix because it's a bit more user-friendly and it's easier for a lot of people to sign up and it's also federated. So you can have your own matrix account and join the Ansible rooms without a problem. And the rooms are also bridged over to IRC. So for those who prefer to remain on IRC, that's not a problem either. The messages show up on both social networks, chat networks. So if you want to get more information, it's in the documentation under communications. And also, of course, there's the community documentation where you can get information on not just the usage of Ansible, but also how to contribute and how to develop for Ansible. So most of these links you can find, that's listed here. And let's see, this is probably another one to keep you parallel. Okay, yeah. So we have several kind of new things that we've worked on in the last year or so, one of which is actually the year before we've had CataCoda self-paced training, which was quite well received. But last year we had this new provider with Instruct. So again, with the link, you can check out some of the self-paced trainings that you can try out. It's mainly for how to contribute to Ansible and how to test your collection, how to create a collection, and things like that. I think there are about five trainings you can go through. And then, of course, if you're willing to take a further step and contribute their information on how you can do that. And there are many ways to contribute, right? It's not just code, which is a major part of things, but also helping to update documentation, run meetups, even though most are virtual now, but there are still activities going on in the meetup world, testing stuff, even writing about your experiences using or contributing to Ansible helps the community. So there's a lot of ways that you can contribute and we appreciate that a lot. And the inclusion policy link, as mentioned earlier, is there as well. And steering committee, that's one of the new things that we set up last year, to give more structure and accountability for the community, right? So that there's a group of people who can help make decisions and make sure that things are being accounted for and make sure that the interests of the community is put ahead as the main priority. So if you want to see what's the story behind it, as well as who are on the community, that's the link to check out. And finally, the new collection reviews is part of the inclusion policy when you want your collections to be included. There's a process and what you need to include to be able to get it for review, to be included in the next release of Ansible. So if you have any questions, feel free to ask them and we hope to get your answers to that. Great. So this is all the slides that Carol and I have. We want to know what would you want to talk about. If you have any questions, please put them in the Q&A or ask to join in. I did see that we got one question. David, are you trying to make things difficult for us or are you just trying to help us? No. I was hopping on to eventually reply to Edward who asked a question on chat but I still got a little bit me to it. Okay. Well, might as well for the audio of it for those people on podcasts. No, I'm joking. Yes. So Edward Lucina asked, I read somewhere that the transition from the Ansible package to Ansible core package will be smooth and perceptible to the user. There's no question mark but I interpreted that as a question as to how does it actually work under the hood? So Gondolo gave part of the answer. The way that it worked is that back in Ansible 2.9, everything was in a singular package. If you went to github.com slash Ansible slash Ansible, you would have everything that was Ansible in this one, Githrepo. And so in 2.10, we changed that where the Ansible Githrepo became Ansible core and then everything else was provided via collections. So the Ansible package from 2.10 and above provides just the collections. So you have Ansible core which provides the runtime that come in line interface and so on. And then you have the Ansible package that adds all of these curated collections on top in order to provide the modules and plugins that you're used to. So if you upgrade from 2.9 to above, it should just work bearing any other breaking changes because well, life being what it is, there are some breaking changes from time to time. And this is why in fact, Tim was talking earlier about how we moved to Semitic versioning. And the Semitic versioning is what is helping us control the introduction of these breaking changes. So we have these 90 or so collections now in the package and we are keeping track of their versions and don't include major releases in such a way that they don't introduce breaking changes until the next major release. So that's what we have Ansible 3, Ansible 4, Ansible 5 and eventually Ansible 6. So my best advice would be to take a look at the porting guide that we have in the release announcements amongst other places. The porting guide and the change log should contain all the information that you need to hopefully make that as soon as possible. The comment is phrased as a transition from Ansible package to Ansible core. Is that something different? If you just have core, you will still need to install the collection separately. Yes. So it depends on the use case, right? I mean, you could install just Ansible core if that's all you need. And then perhaps even cherry pick, you know, install some of the Ansible collections individually. But if you go from the Ansible package and then only install Ansible core, you might end up missing some of those batteries that you were using in your playbooks, right? And so with that in mind, you could continue installing the Ansible package or install those missing collections. So it looks like we have another question in the chat from David Duncan. I can, hey, Dave, I can take that one. Yeah, that is, that is something. So sorry, I should repeat what David says for anyone not looking in. David says moving to 2.12 gave me a surprise in the module shifted from community dot AWS to Amazon dot AWS latest. And he wasn't expecting that. So one of the things that in separating out the content from the core engine in the form of collections is that we had to introduce namespacing because it was very easy for someone to create a module in one collection that could collide with another. So it necessitated namespacing. What happened then is we have all these different collections with their own namespace like community dot AWS and Amazon dot AWS. What has happened in some cases, when you see a community dot, you're sure it's community supported work. Ansible as a product, sorry, I know this is an open source community event, but as a product has created supported content and sometimes we have to migrate the location of content that exists in the community into a different collection that is supported and not just community supported but also supported by Red Hat. So that's what happened there is that we moved modules that were in the community dot AWS into a supported collection which was called Amazon dot AWS. And that's so one of the things that an unfortunate side effect of having to separate out the content is that this namespacing can add a little bit of I guess so I mean complexity is the only other word that you have to track what namespace where you're getting a module from. And if that module moves to a different collection for some reason, then you'll have to update where you're pulling that from. So I think that answers quite an explained what David was talking about in the chat. Yes, and I would add a gundalo replied also in chat. We have to try and not break users when these kind of changes and move a cure, we have a system of the redirection in place. So maybe we missed the redirection, maybe the redirection didn't work, but we do try our best to, ensemble knows to follow these redirections across collections if they're specified. If you do point out the one module in the chat, I'm sure we could look if we'd missed something and we can address it. It's a vibe. Oh, right. Okay, David. So you said EC2 instance, I know from working with that team, they deprecated that module and created a new, I believe they created a new EC2 module. Now I'm getting confused which one was the original and then which one was the new one. But I'm thinking that's possibly why that's one of those rare cases where we we replaced the module rather than ported it. This is a rare thing. I should have said that in what I said is we're trying to keep that these type of situations to a minimum but in the transition, there's a little bit more of that happening. I hope going forward. I'm optimistic going forward. You're going to see a lot less of this type of situation. It's just a little bit of the of the growing pains and going through the transition at that point. But yeah, thank you for that question and your reply there, David. Are there any other questions or are you going to force Caroline to just start? There's another question. There's another question in chat here from David McShane. What's the most unusual device you all have managed slash seen managed with Ansible? Ooh, that's a tough one. Gondolo says Phillips Hue lights. This is true. That's a good one, Gondolo. Yes, and we that was actually done in an Ansible Fest event, I believe, or was it an Ansible Automates event by one of our engineers on stage live. He brought a whole Hue's lights rig and automated it on stage. That was that one was out there. I was thinking of some of the a community member, Jeff Geerling has done a lot with PiPi and PiPi Plus. Yeah, also people don't mention the Pis. Yeah, and he has he has it on his YouTube channel. So it's Geerling guy that he's he's done. I'm thinking he's done some other interesting devices or oddball PiPi devices that he created by hand for very specific purposes around his house. So those are also ones that we see out there. And yes, yeah, this is something we should collect and highlight more. Maybe there'll be a whole new whole new section of the bullhorn there. Right, unusual devices. I don't know if this is an unusual device, but when I used to work with the manage IQ community, we had us like a stack of nooks, the Intel nook units, those small computers. And, you know, we want to set up manage IQ and then run off like Oveard and with, you know, some container cluster with open shift and things like that. So, you know, it's all quite complicated for me to set everything up. But luckily, one of the engineers helped me with an ansible playbook, so that I can just kind of run if I need to, you know, reset the setup to just run the playbook and have everything reset so I can bring the stack of nooks to another event for a demo. So not super unusual devices, but, you know, something really useful. And I will look into the fuel lights as well because we have fuel lights at home and maybe I could do something with that as well. Yeah, Jimmy sees your person, Carol. And I saw, you probably have to scroll back in the chat everyone, but Gondolo posted a link to the demo and notes that that demo was done three years ago. So there might be some porting that needs to happen since then. I don't think, I don't think Jimmy's can continue to maintain that demo. Yeah, one thing I want to point out that's related to that and this is something when I talk to both users and I talk to customers is I point out with ansible, really, actually when it comes to automation, any command line or UI click that you do is an opportunity to automate. If you have those two things, there's a very strong possibility that something that you could also automate. And, you know, if modules don't exist, we have lots of tutorials and a contribution guide to write your own modules that can interact with whatever it is that you're looking to automate, whether it's, you know, a TV or an oddball firewall from the 1970s, I think I just saw go rolling by, you know, or some type of specialized IoT device that if you have a, you know, command line tool for interacting with it, there's a chance you should be able to wrap it with an ansible with some Python code to make it an ansible module and then you can automate that. So no, no, that's terrible, gondola. Some people that have made modules that can only communicate with Telnet and expect, sorry, just think Telnet makes me cringe a little bit just because of how insecure it is. But hey, sometimes that's what you need to do because that's all your options are. So I get it. All right. Any other questions, Q&A, people that want to make an appearance on camera? What about those people who are new to ansible? What would you like to learn about? Great question. Yeah. Anything we can help get you started or guide you? I was actually going to throw a question at the community here. I am an ansible user of only a few years. I use it mainly to automate, you know, setting up cloud instances and things like that. And I find it challenging a lot of times when I'm kind of, you know, because I don't use it daily, I have to return to the documentation. So I go to ansible.com and I start searching around. And it oftentimes seems very challenging for me to find like a good example of how to do what I want. And I'm curious if there's any thoughts in the community or maybe places that I'm not looking that are good entry ways for it. Well, I just need to automate this thing. How do I set up my project? How do I create my playbooks? You know, I guess like a really easy beginner's on ramp to building these things. I'm just curious if you have any thoughts about that. We are actually looking to have somebody help with perhaps like demo videos or just something simple and straightforward with concrete use cases and steps that you do to, you know, like set something up or exactly what you said that, you know, some examples that people can follow and not just because a lot of the time the documentation just tells what this module does and what that collection does, but it doesn't really give you workable examples to, you know, use to work with. So we, we, it's something that we want to work on. And definitely that's a great idea. But in the meantime, you know, we try to share, like I said, in a bullhorn or on Twitter, things that people have done. And, you know, they have examples of what they did or, you know, the challenges they faced and lessons learned. And these are usually quite helpful as well to, to see, oh, okay, he actually tried this thing I was thinking of and, you know, this is what I could do. So if you subscribe to the bullhorn, hopefully you can get some ideas or some, some content that might be, you know, up your alley. If not, please, if you try something and have some experiences with it, do a little video or a short blog post and share that with the community. That's always helpful. Yeah, I mean, that sounds really good. And I think, and please forgive me if my butcher your name, but in chat here, under Ralph says my problem was in begin with folder structure when I'm reading it. And I kind of struggled with a similar thing where I was like, well, how do I, you know, I understand how to run like a single command with Ansible. And I'm starting to understand how to structure my playbook and like, you know, how do I put these things together. So for me, it's really encouraging to hear that you're kind of working towards examples like that. I think I think having a having a little video or something that, you know, I as a user who kind of struggle with this stuff, that would be tremendous. Right. Yeah, sometimes we really need to think from like a, well, not necessarily brand new user, but you know, a lot of times when we are already so involved in the project, we don't see the challenges that people when they first encounter Ansible face. Right, right. And just to be clear, at the API level documentation for Ansible, I think is tremendous. I, you know, when I, you know, because usually what it is is I'll work on Ansible stuff a little bit, and then I'll step away for, for a while, right? And I'll forget all this as it passes out of my memory cache or whatever. And so when I come back to it, and I kind of wrap my head around it again, when I look at the API docs, I think they're fantastic. You know, it's amazing level of detail there. So I mean, kudos to the community on the, on the tremendous amount of documentation that's been built already, but I always seem to stumble over those first few steps whenever I come back to it. And that's great feedbacks. And thanks for that. That's something we can improve on for sure. That's fine. So we have quite a lot of comments. Yeah. Go ahead, Carol. Yes, David Duncan asked the community training was awesome last year. Are we doing it again? Yes. We want to continue the instruct self-paced training and during our events or, you know, it's available also anytime the links are in the slide. Anything else we missed? We talked about the folder structure. Right. Yeah. And just, just having something nice and clean, simple beginner level stuff. I think we covered workshops. Yes. Nice tip here from David about the graph option and the Ansible inventory in visualizing what your inventory looks like and how that hierarchy comes together or how Ansible sees the hierarchy, especially that's very helpful when you're pulling from multiple sources to create that single inventory or at least single inventory view. Is there a nice, more friendly UI for Ansible? I guess that depends on what you consider more friendly. I know some people on their core team right now say what's wrong with Bash. I mean, there is AWX, which is the controller component of the upstream project that is the controller component in the Ansible platform. But that's geared more towards automation across an organization of people than a single user. For example, I'm trying to think of community projects that help create a UI for Ansible that you could run locally. Carl, are you thinking of any or Gumbel or David? Any of the other community team that they've seen out there? In the Q&A, there's a related question, I guess. Is there an alternative to Tower that I could use at home? Essentially, that would be the AWX project, which is the upstream to what was Tower. We've gone through a rebranding again. I don't want to get into product details and all, but the Tower branding has been retired for various business reasons. But you want to look at a project called AWX, which is where our developers work with Red Hat, all about open source. That's where the development happens. And then they snapshot and harden AWX and bring it into the Ansible platform when we do builds. So that's probably what you're looking for. Yeah. And in the comments, Ara is also mentioned. Ara records Ansible. Ara.readthedocs.io, which you can take a look at, see if it fits your needs. It's mainly for recording and reporting. David, would you like to talk more about Ara? David from my team. David's in the chat here. Exactly. I had the job earlier, I guess, on technical difficulties to use bikes. You know how it is. So yes, I do have a talk about Ara at Fosdom next week. And not to do two birds, one stone kind of thing, but there will be a spoiler. There will be a demo where I spin up an AWX instance on top of a simple KTS node. So that is suitable for running at home. It's not, you know, if you have like a home lab or something like that to manage your stuff. It's something that you could stand up. I mean, I do it in the live demo within a few minutes. So it's not, you know, that complicated to stand up. And so, by all means, check that talk out next week. Maybe it could help you. Yeah. And to add to that, Gundalo here put in the chat for anyone who's not following along, that there is now a VS Code plugin for those. It doesn't help you run Ansible locally, but it does give you, for those of you that are more comfortable on IDE, particularly via VS Code, the ability to write your Ansible content, it just makes it easier because it gives all those extras that you've come accustomed to in IDE, but for writing Ansible content in there. So the link, the link is in the chat for those that want to try that out. Another tool that I haven't seen mentioned is Ansible Navigator. So Ansible Navigator is a new tool. It's not, I don't think it qualifies as a graphical user interface. It's a text UI. Right. So within your shell or your terminal, you have this Ansible Navigator UI where you can run playbooks. And it knows about this relatively new concept of execution environments, which are container images where Ansible can run from. So if you run Emax and you have your emails and your terminal, and you have your IRC bouncer in your terminal, and you love your terminal, Ansible Navigator might be very interesting to you. Yeah. That's a topic just for FYI. That is something I'll go into in my presentation tomorrow with a little more depth and some slides to work from. But that is definitely something to check out. It is, like they've said, it's a bit of a leap because it's getting into this thing called execution environments that we've introduced. It's more related to AWX and scaling, dynamic scaling of doing large amounts of automation. But I think there is some potential there for what it can do for running Ansible locally and making development easier for individual developers. But that wasn't the main focus of that project out of the gate. But I think there's definitely some potential there for the community. So. Yes, I've seen a workflow where, and sorry, I had to cut my video, video subuspects. I've seen a workflow where people use the VS Code with the VS Code Ansible plugin, and then they have a terminal open at the bottom of VS Code, and then they have Ansible Navigator running on there. So it's kind of like everything integrated. It's pretty nice if you're into that. Yep. Okay. Is there any other time, Michael? Do we have the whole hour or? Technically, you have about six more minutes. Okay. Okay. So if anyone else wants to jump on camera now's the time, like make your requests. Yes. Yes. If you're being shy, you need to get over it. We won't bite. Yes, we don't bite. Here comes someone who's never shy. Hello. Hi. Hi, Neil. Hello. Good to see you. Well, you know, you wanted someone to come up and I was like, yeah, you know what, why the heck not? I'm super new to the whole Ansible thing. I've only seriously started using Ansible, I don't know, five months ago. Okay. So I have very unhappily lived in the world of Puppet for like six years now. It is a very interesting difference between Puppet and Ansible. I mean, I've used all of them, Chef, Puppet, Ansible, Salt, them all, but like it's a very interesting dichotomy and I think I like the Ansible side of things a lot more than I have the Puppet ones, but I also think that might mostly be because Ansible documentation is very good. So like props to y'all that the documentation for Ansible is very good and I can actually understand what the heck I'm doing when I'm using something. But I will say that one thing that's been going on, my time starting in Ansible has also been the most confusing because this big transition around Ansible has been happening at the same bloody time and I have very little clue about what I'm supposed to be using or doing or whatever because like the world seems a little splintered between the Ansible 2.9 classical one and whatever version the new one is because like I've now heard Ansible 3, Ansible 5, Ansible 6, Ansible 2.12, I have no idea what is going on and I am so very confused. You have to attend Tim's talk tomorrow where he will go into the details about what happened. Yes, since you're here, I mean I can try for a minute or two to explain that for you, Neil, but yes, Carol's through that. I do have a lot more slides that actually illustrate this and I illustrate is truly the word for it. So the quickest explanation I can give you, I understand and feel your pain, was an unfortunate necessary thing that we had to go through. I've been talking about this for a couple of years. Some people out there might have heard me speak about this. From the earliest days, everything was all in one package and it served Ansible really well and it made it really simple. You didn't have to deal with a package manager and have compatibility problems. It's like whatever you had in there is what worked with the engine and life was good. The problem that we ran into is that the use cases and the growth of the number of modules that were out there were becoming so large that it was making it really hard to test and release Ansible anymore. It was starting to, in a way, collapse under its own weight or become a victim of its own success. I think as I mentioned, I think in the 2.9, we maybe breached 4,000 modules and this is going across network and security and cloud and Windows and Linux and all sorts of things. It was really slowing down releases and someone plotted the growth curve of Ansible content and it was just going through the roof. We had to make this difficult decision that we had to separate out content from the core engine. There just wasn't much of an option anymore that we had to rip the Band-Aid off and go out and do that. That's what happened between 2.9 and 2.10. We started prepping in terms of engineering work in 2.7. We did a preview in 2.8 and then 2.9 was the first one where you could use these things called collections and collections are the ways that all this Ansible content can live separately from the engine. That's that transition that unfortunately you've had to go through is that instead of having this one integrated thing that now you have a core engine which is the runtime, the handful of modules that really you can't do anything with the runtime without them and that's that 2.9, 2.10, 2.11, 2.12 project. But then there's still that desire for people to have that. I install one thing and I get all this stuff and that's what that Ansible community project was that we talked about earlier and I'll jump back to that slide. We decided to give a different versioning scheme so that you can keep the two separate. So there's the core engine that everyone knew of but now all the content's been removed out of that after 2.9 and then the package everyone is used to installing is the Ansible community package and that has versions like 3.00, 4.00 the current most stable release is 5.2.0 and as Carol said very shortly there's going to be a 5.3.0 that simulates that pip install Ansible package you used to get. That was we've really obsessed over this and rung our hands and trying to make this as seamless a transition but there's only so much you can do with that type of significant change in the packaging and even to a degree the architecture of the application itself. So I don't know if that quite answers your question and the it totally does. I'll attend your thing tomorrow. Yes and please ask questions if I don't explain it well enough. Like I said I have a bunch of slides and illustrations that explain that in a little more detail than what I just gave you. And if you would like to continue the conversation, Michael Botech has put a link into chat here to the work adventure experience where you can continue to have a little bit of a VR experience with the people in this discussion. But I'd like to say thank you Carol and Tim. This has been a great session. Lots of good conversation. Thank you to everyone coming out as well. Thank you Michael. Thank you and thanks for everyone who joined us in this session. Likewise. We'll see Carol and I are going to hop over to work adventure. Right. Let's do that. Hopefully we'll see some of you there. Thanks all. Bye-bye. Have a great day, Kyle.