Currently, the official Ansible Engine release process is the only way for users to utilize or consume new content easily. The Ansible community has begun the journey of providing our users with more flexibility to create and consume content. In this webinar, we'll discuss where this journey started, where we are currently, and where we would like some feedback.
Chris Short: Good morning, good afternoon, good evening. Wherever you are, welcome. Thank you for joining us today on this glorious webinar where myself and Dylan Silva will talk about all the future of how Ansible content is being handled. Just some quick notes. This is being recorded. I will share this as soon as I can after it is done. Maybe a couple hours after it should be up. Hopefully end of day. The questions, there is a questions box in the Go to Webinar control panel. Feel free to ask there as Dylan and I are speaking. I will attempt to answer a many as possible and hopefully we'll have some time at the end to answer all of them if need be.
Chris: If there is something wrong with your connection, I can't help you with that. I'm sorry. But please try to reconnect if you do want to continue to attempt to get the content. So sometimes Go to Webinar has problems like we just had so you have to reconnect and it magically works. Yay, technology.
Chris: All right. Ready to kick it off, Dylan?
Dylan Silva: Yep, let's have at it.
Chris: So how about you introduce yourself first for everybody. I'm the Principle Marketing Manager at Ansible and you are, sir?
Dylan: I am the Product Manager for Ansible core, Ansible engine, Ansible project, whatever the heck you want to call it.
Chris: So to be clear, it is Ansible, right? That's your official title? It just says Ansible because we couldn't nail it down.
Dylan: Yep. Pretty much. And name's stick so you kind of just go with the flow and ride those waves and have some fun so when you sit in meetings all day and talk to customers and users, just keep it as people know it. So yeah, that's me.
Chris: Awesome. So we are talking about something you are very passionate about. The future of Ansible content and how it's packaged, handled, distributed, the whole nine yards, right? So this is your ballgame.
Dylan: Yep. So I'm dragging you along for the ride obviously but just kind of wanted to talk with everybody on the phone here with us about what the current state is of the Ansible project, how content and how contributors are contributing to the project today. So you can see here a few stats that we're very proud of that we like to always bring up to everyone to see. So we have our right number of forks, around roughly 15,000, a little bit over that, 37,000 stars, 45,000 plus commits, unique contributors over 4000. New number as of the latest release we have around 2800 modules that we're shipping with today in Ansible which is just insane. And the 450 pull requests is by no means the total number of pull requests right now. That's roughly around 1600 plus last I looked at it, but this 450 pull request number that I'm showing here is the on average number of pull requests that are in at any given time for existing modules or new modules that are coming into Ansible. So it's just an insane number.
Chris: Yeah, those last two numbers on the screen here, 2800 modules, 450 pull requests just around modules, either new or existing I think is an enormous amount of effort that has to get put into releasing Ansible every single release. I mean I don't know if we can share numbers, but there's not a bazillion Ansible engineers working on this, right? So I think the idea is to kind of help lift that load a little bit maybe.
Dylan: Yeah, no totally. And there's other reasons why too that we're talking about lifting a load so to speak. We want to clearly state there's a difference between the engine itself, why its called the engine and the people that are there maintaining and contributing to the engine compared to the people that are very vibrant in the community and want to provide content for Ansible to do its awesome magic. So giving us that opportunity to split the love so to speak and actually show how vibrant it is is why we're having this discussion today.
Chris: Great, yeah. I think the one thing that people don't realize is that if you look at it from a, let's look at race cars for example. A normal pit stop in NASCAR racing, F1 whatever, the engine in the car comes in and then all these people do all this stuff around it and then it leaves, right? But no one's waiting for the engine mechanic to green light the tire jack man to lift the car up and then the individual tire, all those pieces happen at once and I don't think we can have an official Ansible pit stop right now. We have to roll the whole thing under, pick up the body, and then work on the whole thing all at once, and then drop the body back down and ship it off again, right?
Dylan: Yep. Totally. And to segue a little bit too, the concept here is that there is just so much content everywhere, and we ourselves have tried to create pit stops, right? One pit stop to think about here is Ansible Galaxy. We've created a pit stop for roles.
Chris: Right. People don't realize how good Galaxy has become. I believe Galaxy is a totally suitable place to look for solid recommendations on automation in Enterprise environments, production, development, whatever, customer-facing or not. I don't think that enough people respect or know about Galaxy, if that makes sense, right now, so this part of this webinar is to make sure that people are aware of what Galaxy is.
Dylan: Yeah, definitely. And it's really how does one operate in their environments? It's not on us, Red Hat, Ansible, whatever you want to call us to make the assumption that you as a user can utilize Galaxy to its fullest extent as it stands today, right? Because you may not have that ability to connect to Galaxy from the system that you're managing your environment from; your control node as we like to call it.
Chris: I think the prime example of that is two gentlemen at Ansible Fest last year approached me and they're from Taiwan and they just, the latency in connecting to Ansible Galaxy was too high for them so they were trying to figure out other ways to distribute content.
Dylan: Which is crazy, right? Because the amount of content in Galaxy is vast. There are a lot of roles on there, but roles in the big scheme of things are tiny. They're not large pieces of content that we have to think about. And that's the kind of thing is when you're operating a service like Galaxy, we ourselves tend to forget that it's hard, it's very hard to manage a service and for people to utilize content and just from one location. I mean, I myself before I was an employee of Ansible, I used Galaxy as just a reference point. I never once downloaded stuff from Galaxy.
Chris: Right, like I would download it and change it, but I would never say, "Hey, we're using this straight out of the box."
Dylan: Yep, and see, I wouldn't even do that. We had a mode of operation. If you need an idea, feel free to go to Galaxy, but you better not download that crap. I'm going to paint the kettle black. Back then-
Chris: Go ahead.
Dylan: ... different world. And it's definitely changed now. There is so much quality content out there and I still probably couldn't this day conceive downloading Galaxy content because it just doesn't fit with my process and the internal sharing of content is a whole other ball of wax that you have to think of when you're downloading content from the community in Galaxy. And there might be licensing issues or I'm referring to compliance gray areas that we had to adhere to because we were in the process of going public. So there's so many... that we ourselves at Ansible just cannot assume can work. And what are some other ways of sharing content? I think putting content onto a thumb drive and walking it over to a person to have a conversation or we used Gerrit as our Git choice of our process, but we had a large operations team. We had regular operators that didn't understand Git. We were, Git was still a new thing back then and I don't know about you, but I would spend weeks trying to train new operators on how to use GET and it would be just to check out content.
Chris: Right, just to get something from Git is not exactly an easy lift.
Dylan: Ultimately, it just doesn't work, so we're taking a step back as a product team and as an organization here at Red Hat and thinking what can we do to make things better, right? And obviously today things are distributor in the Ansible package. You have your plugins or your modules and I always like to remind people that modules are plugins, FYI, but I digress.
Dylan: It's dependent on having that content within the Ansible package for people to easily utilize it, to simply call that content. It needs to be there. And you can put things into roles, back to Ansible Galaxy and distributing roles and the Get workflow or sneakernet. All of those problems keep wrapping back around.
Chris: Yeah, the number of times as a dev ops consultant I walked into an org and saw GitLab as kind of an Ansible distribution point and then all the weird workflow scenarios after checkout that you have to do to make it work just it wasn't intuitive and always seemed to require a little bit more work.
Dylan: Yeah, totally. And it's not to say that these things aren't working because they totally are. It's just we need to have the onus on ourselves to give the best experience that we can to our users, to our content providers or our creators as we like to call them. So what are those user experiences and processes that we can start to implement over the next few years if I'm going to be honest to start this and make it a better user experience? What is the journey that we can go on and why will we change what isn't broken?
Chris: Right. Ansible works great for a lot of people. It's the Lingua Franca of automation in a lot of IT organizations currently. So the idea of mucking with this thing that's working very well scares people. It's like changing the Facebook homepage. People might not like it originally. So we're kind of slowly stepping out about this. We want to think about what we're distributing, how we're distributing it and then how to make that more manageable for our friends and customers, correct?
Dylan: Yep, correct. Totally. And we have a lot of people that we have to think about too. Obviously our customers, our users, we obviously love everyone and love to think about everyone in that context, but we have as you all saw earlier a large community and community to us isn't just the people maintaining and contributing code, it is our users as well, but there's four themes here that really I think about when me and the team think about what it our approach to this. And when we break it down, we want to give our community the independence to work at their own pace, to remove the reliance from us on the core maintainers, the core engine producers to provide them content. We don't want to be a bottleneck. That's one of my biggest pet peeves is a single point of failure and I consider our current processes a single point of failure. We're a victim of our own success.
Chris: Right. And I think that's something that people don't realize is that single points of failure can extend beyond architecture of IT. It could be a process or a team that is a single point of failure for example, right? Like if everything has to get routed through your help desk and all of a sudden your help desk loses everything, your organization grinds to a halt? That's not the right answer. That doesn't make sense. So it's the same kind of scenario here with our code base, right? We have people that want to contribute lots of things into the code base, but because of the way we've structured it and it made perfect sense in the very beginning, we're suffering for this need to increase throughput, so we're discussing ways or doing that.
Dylan: Yep, totally. And that's a good point to bring up too is when we walk about partners, I'm on numerous conversations with our partner engineering teams as well as our business development folks and product managers for partners and there's always pain points that we're facing day to day. So for our partners, we want to allow them to keep working the way that they know and worked for them and their development processes. And as much as we want to force them to adhere to our development process, that just may not work for them and our process is really built around developing the engine. And we can only go so far as to dictate how they are to support their content that they're provided us as certified.
Chris: Yeah, I think it's important to point out even our partners that are large cloud providers that contribute modules to Ansible, they don't spend a lot of time making them. They've auto generated them to a certain extent where its just, they can ship it whenever they or us makes changes. It's trivial to them. But we can't import it as easily.
Dylan: See and you bring up a great point there too is the motion of them "shipping" that content. Referencing back to what I said earlier is Ansible as it stands today is more or less dependent on that content being packaged and delivered with Ansible for people to simply use it. And I for one am not happy with that for a myriad of reasons, but from the partner perspective, I'm not happy with that because I want them to operate on their own teams and for us to just certify at those certain points that things are okay and not have them bottle necked or roadblocked by the release process of an engine that is obviously on a slower cadence because it needs to be stable for the users. It needs to be stable for the partners to develop content for the users.
Chris: I think people don't look at Ansible engine in the same way they look at something like Red Hat Enterprise Linux. The platform but be statement and consistent. Everybody innovates on top of the platform and engine really is the platform for the entire Ansible community.
Dylan: Yes, totally. I couldn't agree more. And moving on to the customer's piece of this too is when we're talking about the platform here, we want to give a sense of control that the users when they have Ansible tower in their environment, when they're running engine under Ansible tower for that platform and they're building out their automation, we want Ansible automation to be as controlled by them as they possibly could. We want them to be able to choose what content they want in their environments, how they're going to leverage it and at what cadence they, themselves want to be able to deliver that content internally without having to jump through those hoops.
Chris: So what are we doing to help with that? There's a lot going on here. Talk to me.
Dylan: Yeah, there is. So when we talk about the innovation, we're taking that step back and we're thinking about how to we enable people to innovate more? So we've come up with a couple of concepts. We, in Ansible 2.8 have a tech preview of an it, called a collection. So what is a collection? A collection is a "package." Granted, I don't want to call it a package management system or anything like that, but you could call it that.
Chris: You're managing your own dependencies here.
Dylan: We're managing a lot of things here, but a collection is a way for users to take a set of content. Presently it's plugins and roles and bundle it up into a tarball and take that tarball and manage it in the way that you presently wanted to manage it. So that could be back to the sneakernet realm or you could have your own artifact repositories on your local data center. There's a myriad of ways, obviously, that you could manage this content.
Chris: Throw it in an S3 bucket, you could use an internal FTP server if you wanted. Yeah, it's a tarball. Do what you want with you.
Dylan: Have fun with it, but the cool thing about this collection package is the collection itself is a very strict format. It isn't as willy nilly as I like to say that roles can be. It's roles plus plus. It isn't a drastic change of a project format by any means. I like to call it the new project format of Ansible. We'll figure that out in the future if that's really how it's going to be marketed, but anyways I digress. It's us saying this is how we want content to look like and for it to be delivered. No longer are plugins living under roles. They're living at the top directory of this collection.
Chris: Thank you.
Dylan: Yeah, I know. These pieces of content will be "installed" on the node that it's required to be installed on whether it's the control node or the manage node. It really depends on where you're calling these plugins from or roles from, but effectively, Ansible will know these collections exist and are installed and can easily and simply utilize the content within.
Chris: Can we walk over the tree here that you're showing on the screen real quick? There's a few things I think that might be slightly foreign to run of the mill Ansible users, Ansible engine users, specifically the galaxy.yml file and then the need for the meta directories underneath each role.
Dylan: Okay. So those are all good points. I won't go too much into ...
Chris: Not a deep dive, but definitely the galaxy.yml. Why is that there, top level?
Dylan: That's a good call out. So the galaxy.yml file that you're seeing here, Chris, is actually if I was developing or creating the content right now, the galaxy.yml file is effectively the metadata for the collection as a whole. So this file will essentially be telling Ansible Galaxy what is contained within. When a content creator builds their collection, this galaxy.yml file and the content in it will be transformed into a JSON file. So it actually disappears and is transformed into a manifest .JSON file that Galaxy slurps up upon publish of this collection.
Dylan: So there's a bit of requirements, hard requirements for it to work. And those requirements are listed in documentation, but that's what that's for.
Chris: Sweet. So you mentioned documentation. Obviously where is that for people that want to look a little bit further into the structure and what's required for collections itself?
Dylan: Sure. So both for installing collections and creating collections today, the documentation presently exists on Ansible Galaxy docs section. We're in the process of trimming it down and putting bits and pieces on docs.ansible.com and some of it will still continue to live on Ansible Galaxy. Just in short, we're working on a very seamless documentation experience between the two websites so stay tuned for more of that which I will talk more about in the future as well. As of today, Ansible Galaxy docs is where you see that stuff.
Chris: Cool. I dropped that in the chat for everybody to see.
Dylan: Cool. Thanks.
Chris: So this is good. We now have a content format for example. We are setting a standard and we're trying to work towards solidifying the standard. We have identified that we need it and we need it to work for more people. So what is the tooling going on behind the scenes and trying to hammer this into shape?
Dylan: There's a lot of tooling considerations that are going into this, but right now the main focus is on two things. One users on the call right now and yourself, I know you've definitely heard about this. There's a project out there called Mazer that that's been our development branch of everything that is collections based. My comrade on the team, Tim Appnel helped lead the charge of Mazer. Man, I think it's been almost two years now that we've been embarking on this journey, and he did such a great job at starting that and getting people moving with it, but Mazer is the interaction point as of today for collections. We never had intended for it to be the long-term end result so we're in the process of migrating the functionality of Mazer back into the Ansible Galaxy command line tool.
Chris: I think it's important to note something as big as Mazer or potentially as big as Mazer was vitally important to develop out of the Ansible Galaxy tree.
Dylan: Yes, yes, definitely. We've done it a few times just outside of the Ansible distribution itself. We've done a few branches on quite a few things and it's worked for us. Mazer was a big enough change and something that why it was a separate project, we weren't even sure if this was something that we wanted to do. We weren't 100% convinced ourselves that this was a journey that was going to go anywhere. Well, now we do know that it is definitely somewhere we want to go. So we're doing the needful of migrating this functionality back in in this software release cycle. So that's what we're actively working on. I'm going to do a blog post along with you around this in the next few weeks. We'll drop a link into the PR if it still exists by that point. If not, we'll say hey, in devel branch Ansible Galaxy CLI is going to be working with collections. We'll see based on where that timing lies, but that's where we're at right now on that one. Go ahead.
Chris: Yeah, so some of this functionality is in Mazer. Most of it's moving to Ansible Galaxy, the CLI tool. You mentioned docs are being written, writing more docs.ansible.com. I know there's a ton of effort that we're putting into docs right now just in general and we've always been pretty good about docs. Maybe slacked the past little ways, but we're getting better on that. So if people have feedback, let's say the people on the call are actively kicking the tires on this right now. I'm not saying that they have to be or anything, but it would be cool if you were. If they have feedback on, "Hey, I think we should tweak this," should they send it through normal GitHub PR channels or where is that going to go?
Dylan: Yeah, definitely GitHub issues are more than welcome, Ansible project list, I lurk Reddit quite a bit.
Chris: Yes. I don't think people realize enough how many people on the Ansible team lurk Reddit.
Dylan: And as always, the sub for Ansible is very vibrant just like all other sub Reddits out there. So there are a lot of people there, and I do lurk where else? On IRC too obviously. Drop some stuff in there too.
Chris: Cool. So basically all the normal feedback channels for Ansible are available to anyone wanting to talk about collections. I think that's the biggest thing here. It's not like it's one-off team or some small little group that's still working on this. It is now a full fledged thing that we are in the process of production-izing, for lack of a better term.
Chris: So around that, the idea of installing a collection. I can put the docs, I think I did. No, creating them. I'll put the link for installing them, but kind of walk me through that process. I've created my collection. I have everything I want where I want it. It all works supposedly as I want it. Now I need to install it. What is the actual mechanics of that that you see in the future?
Dylan: So I don't want to give away too many spoilers, but the initial spoiler that I will give away is what is there today with the command lines. So for a user, it's very simple because obviously we like simple processes here when it comes to Ansible. It's one command. It'll be Ansible Galaxy collection install, the organization or the namespace dot the collection name. And if there's a version you can also specify a version. Once that's done, those collections are immediately installed into a collections path that is defined by the user. We're going to make the call that a collections path by default is not defined.
Chris: Oh, okay.
Dylan: And the reason why is we don't want to impose a lot on the user. We want to give a safe assumption that the user could be just an operator or a user or an administrator is setting up their tower environment and the tower has its own file paths that it has to deal with to operate. We don't want to set the this default and expect people to have that go across their whole development lifecycle. So by default there isn't one set. So just wanted to call that out, but once that collections path is defined, Ansible collections are installed to that path and then the user can then specify how to utilize that content and that looks like this.
Chris: Okay. So tasks, all right, cool. So ah, I can see. The three tasks here are you calling out a namespace, a organization, and a role here it looks like, right?
Dylan: Yep, exactly.
Chris: And the Ansible built in and then Ansible legacy, what are those? Yeah, walk me through this file you're showing us here.
Dylan: Sure. So another big change that we introduced is the concept of name spacing of content. So now that we have content coming from various locations, there is most likely going to be the same name of a plug in in those multiple locations. So we have to think about how that is handled. So this name spacing helps with that. So users get to specify what collections they want to utilize in their playbooks. So that is the collections line, effectively line two here. That's the call out there. And then from the tasks, foo.pinger.ping is coming from the foo.pinger collection. So foo being the namespace, pinger being the name of the collection.
Dylan: When you drop down to the second task, Ansible.builtin, that is our own present magical builtin modules as they live today. And then same for ansible.legacy. Those are effectively built ins as well, but just the different structure of those this is how folks call the built ins. And then of course the shorthand still exists today as well.
Chris: So the shorthand would work to call the full blown collection if it's just Ansible.builtin kind of thing, right?
Dylan: Yes. Or it will walk the path and see, "Oh, is there a ping in the collection?" The first bound that I do it will utilize that one.
Chris: So it will defer to your collection before it defers to internally based one?
Dylan: It defers into the order that you have that's specified.
Chris: Good call. Because again, flexibility.
Chris: Yeah, so I see a lot of potential here for distribution and I'm going to go ahead and ask the question now and I know you probably don't necessarily want to answer it but it's in the channel so we have to answer it. Daniel Linder asks about Galaxy and the Enterprise. I think you can connect the dots here. If you have a good collection and a decent way to distribute them organizationally, that is your galaxy at that point. Now, what that thing is that you're distributing it from, we'll see what that might end up being in the future. Is that just going to be something that we suggest, have a few suggestions for like we do for kick starts and RHEL installs or is this something that we're going to put something around it?
Dylan: Oh we're totally putting something around it.
Chris: I like the sound of that.
Dylan: I'm not going to be telling much, but we definitely have a lot up our sleeves and we have a kick ass experience that we're mustering up here for our users on this because there is so much room for growth now that we have this. Ultimately, we want to bring everybody together and I can't stress enough that I'm super excited for what we have coming down the pipeline for our users. There is just so much cool stuff that we're working on in the background, and I can't wait for everyone to see what it is that we're doing. There's some cool stuff. So as a final segue, if you all want to hear what we're going to be showing and talking about, Chris, where should they come?
Chris: Well, I think we've got a thing that could help them figure out what's going to happen next, and you could actually get yourself hands dirty during it. It's like thing called Ansiblefest and this year we're going to Atlanta. Ansiblefest Atlanta, you all. September 24th through 26th. There will be a welcome party the evening of the 23rd of September. It's the same format as last year so that welcome party, two days of awesome content and then workshops afterwards. We're expanding some of the workshops that are going to be given there. So that'll be awesome because enough people liked some of the add on options we had last year. We're going to increase capacity and add a few more. But I think the biggest thing for folks on this call, if you really, really, really want to get your hands dirty with collections, the contributor summit on September 23rd, that day before Ansiblefest actually kicks off, last year I went to that and I got more development experience I feel like in the Ansible land than I've had in the past four or five years using Ansible. So definitely highly encourage you to go to that if you want to be involved in this process.
Chris: Dylan, what specifically are you doing around fest though?
Dylan: Well, I'm definitely going to be talking about all of this and all of the fun stuff that's coming. Specifically around collections, I'm going to be just hammering on people to get feedback, just talking with as many people as I can to hear the initial feedback for the people that this is going to be new to because obviously it's a big world. Not everybody's going to catch this what we're talking about today. But for those that have had the chance to test it in between now and September, just to hear that feedback about how the development cycle has been doing and how the journey has been for them thus far. So my voice will be gone by the end of the Ansiblefest timeframe. That's for sure.
Chris: Yeah, I think everybody's voice is usually gone if you're on the Red Hat Ansible team for Ansiblefest. So just to let you know everybody out there, super early bird pricing ends June 30th. So right now is literally the cheapest rate to get an Ansiblefest ticket. Also locking in hotel rates will be cheaper now than later more than likely. So the sooner the better to get your Ansiblefest tickets. Let's go through any unanswered questions you may have. Is there anything else you want to jump on that you might have forgotten you think?
Dylan: No, I think we're good here. Definitely ready to bounce onto questions.
Chris: All right. Here's a hard one for you. Are you still actively developing Open Source Galaxy?
Chris: That's this, right?
Dylan: That is this. I mean, that's how we operate. Everything is more or less up stream first and then we package everything downstream.
Chris: So are we updating the roadmaps doc for that or is it in another place now?
Dylan: For Ansible Galaxy, good question, I'll have to get back to everyone on that. We'll point to those once I figure that. I'm not the PM for Galaxy. That's another person on my team.
Chris: Yeah, yeah. I just want to make sure that folks know it's definitely something we are working on. The actual roadmaps documents are something that I think per project in flux depending upon which project you're working on.
Dylan: Yeah. Just one call out I'd like to do real quick is Ansible Galaxy community is definitely being developed. The latest release of that came out last week or two weeks ago now. It was the beginning of June. That's where we introduce collections support in community Galaxy. If you go to Galaxy today, you'll see about five collections now last I checked already existing in Galaxy. So people are already kicking tires on that. And we're already reaching out to those individuals and starting to gather feedback and everything is good as could be.
Chris: Yeah, the more people we have contributing to this, the better it will be right? That's Open Source. We're going to get more diversity and thought into this thing so that we make sure we get it right for the majority of use cases. Because we don't want to end up in this scenario three years from now where we're like we didn't do collections quite right. And it might be that maybe we didn't do collections quite right and we needed to think bigger but we don't want to miss the mark and make it unusable either.
Chris: So there's a question here about installing directly from GitLab instead of Galaxy. I believe you can install a role directly from GitLab as long as you can connect to it. So if GitLab, you just say instead of role, it's the path right? The actual URL?
Dylan: Yep, it's just SCM URL at that point.
Chris: Okay. Cool.
Dylan: One point of clarification for collections though that is not the case. So the collection isn't dependent on that package. It's dependent on Ansible Galaxy. So how you download the package itself is, right now, a manual process, but we're working on making that more seamless.
Dylan: So it's not longer SCM based. Part of the problem here is that Ansible Galaxy is very married to GitHub.
Chris: Painfully so. Yes.
Dylan: So it's hard for us to work with GitLab or the other Get-based tools. So we've divorced ourselves from GitHub by making this a package format and we're going to adhere to that for the near future. I know a lot of people right now are thinking, well, that sucks because even I said you can't use Galaxy but spoilers, we're working on this and stay tuned.
Chris: Yes, I think if anybody's asking for an Enterprise Galaxy, they might want to hang around a little bit longer. Come to AnsibleFest maybe.
Chris: So Let's see. Going down the list. I can't pronounce the name. The last name "Domanowski" has two questions. Seemed be a little confused. Can you pull up the collections tree that you had up there a minute ago. So are the tasks "whole roles" being called? Are role-dependent variables supported? So obviously I would think yes, right? The tasks are actually full blown roles. Namespace, the organization, and then the actual role is ping here for foo.pinger.ping. I'm sorry, correct me then, please.
Dylan: So actually, so these are just tasks. So foo.pinger.ping, that is the fully qualified name of the module. So this is an actual task action.
Chris: Okay. So the module could be run as a task or the task could indeed be a module. It's just in the collection. It's very flexible is what you're saying?
Dylan: Correct. And this is contained, so the role, so if this was within the role that is it the collection, you could immediately revert to the short name of that because it's calling it from within the collection itself. Does that make sense?
Chris: Yes. It makes sense to me. Hopefully it makes sense to the person that asked the question.
Dylan: To reiterate it more simply, if you call a module or a plugin within the role that is contained in the collection, you can do the shortening because the collection itself assumes you are calling that module within it. But if you want to be very specific, you can do the full name. That is spelt out here as first task.
Chris: Yeah, and I would encourage everybody to be as specific as their organizational needs require then to be. I think if you leave yourself open to ambiguity here, you might find that there is multiple things that might have the same name if you're not careful.
Chris: Especially right now with 2800 modules. So speaking of that right, with the current modules in Ansible core, they're all sitting there, Anshul asks will they need to be copied over to collections? What will they have to do as a partner or module contributor to port modules over. Nothing right? This is literally just a way of packaging things right?
Dylan: Correct. So we're actively thinking about what this means for the future of distribution of content. And we by no means have all the answers lined up here so we're still thinking about it. But yes, it is safe to assume that things will change and as we have more information as it becomes available, we will provide it to everybody. But there are a lot kinks that we have to work out from tooling to CI to everything to make this still a seamless experience.
Chris: Yeah, I think people need to realize the idea is not to make this hard. That's not the Ansible way. The idea is to make this literally as easy as possible for people, as easy as possible as we can make it, right?
Dylan: Yep. So like I said, this is a journey. It's going to take, we have to do this right. It is going to take time. If we just pulled the trigger on it, people would not be happy.
Dylan: We have our community. So we have to take a lot of things into account. There is going to be some pain incurred in some places, but we're doing our best to make it behind the scenes, and the pain be on us operationally and for the users and the consumer, our consumers and our creators we want it to be as seamless as possible.
Chris: Right. Consumers, creators, contributors, the whole nine yards. We love everybody and want to make their lives better. That's kind of the mantra.
Chris: So looking through the last of the questions here. I guess we could. Do you plan to implement collection GPG signatures? We have a certified content program. I don't think it's be hard for us to have certified collections with GPG signatures if we really wanted to. I don't know if that's in the roadmap, but we can upstream that unless you already have something there for that, Dylan.
Dylan: We're definitely thinking of things that we're thinking about how do we definitely, how does certification fit into all of this. Once again, spoilers, don't want to give away too much. Definitely all things that we're actively thinking about and working on.
Chris: Cool. All right. So is there a demo collection out there that someone-
Dylan: There is.
Chris: ... could download and actually use right now?
Dylan: There is. It's on Ansible Galaxy. So if you go to, yep, cool thing about it is collections surface first within the search function in Galaxy so if a user goes to galaxy.ansible.com and-
Chris: Yeah, go ahead. Show them.
Dylan: So if you click on search right at the top you got five collections.
Chris: Yeah, and while we're there, keep in mind we're scoring these collections and while a collection has metadata in it essentially for the most part, we dive down with the scoring system and try to look a little bit further than just that.
Dylan: Yep. And you can see too, so this collection itself contains content within it obviously, and we tag what type of content it is. So whether it's a module or it's a role. It's very clear what it is and then you can see versions and tags associated to it, the README, and there's a lot more coming with this. So just stay tuned.
Chris: The first collection is a collection demo. The second collection is how to set up a development environment for making Ansible roles. Those are, I feel, the first two things you have to have to suitably have a collection, right? As a demo process. Give me the demo. Show me how it could work and then, oh, yeah, how am I going to use this thing to now make the thing. You can't go from that to that. Your project might not be ready yet. So I like the idea of having a development environment collection that I just run and I'm ready to install and work in Ansible land, because that took a little bit of time to get all up and running once I started here at Red Hat.
Chris: Anything else? I don't see any more questions that need to be answered. Let me, no, no. Drew Mullen, Ansible Molecule is the official test framework? It is the official test framework of Ansible but not in Ansible Galaxy at the moment. So what is the scoring being done here? It is not Ansible Galaxy, it is actually Mazer I think, right?
Dylan: It's a system in the backend. It's running some linting...
Chris: Yeah, yeah, yeah. So it will seamlessly run in Ansible. Whether or not it validly runs is the next question.
Dylan: Yeah, so Molecule we did adopt. Another thing that Tim Apnal helped lead the charge on, but from an engine standpoint, what myself and the team are doing is we're taking a lot of thought into now that it's adopted by the Ansible community, how do we make it more and really push it. So those are things that are coming into consideration and just stay tuned for more information.
Chris: Yeah, I got pulled into some Molecule development work for the Kubernetes based operators with Ansible. So we've done some work with Molecule already internally to use it to do wonderful things with stuff we're working on.
Dylan: It's an awesome tool. I love it. I'm happy it's a part of the projects that we support and back. I can't wait to do some more cool stuff with it.
Chris: Yeah, I would like to do a Molecule demo of some sort at fest, and then trying to explain to people, I'm working really hard now with our network engineers to get them on board with testing with Molecule because I really feel like I could save them time. Because a lot of their stuff is virtual, but a lot of it is not.
Dylan: Yep, just one last bit about Molecule too is that at Red Hat Summit, I talked about Molecule, and we did a presentation similar to this at Summit. I envision Molecule becoming the creators' SDK if you will for writing Ansible content. It has a lot of great tool sets in it and it has a lot of plug in points to the various other tools that live with Ansible. So we're putting a lot into it to make it that. It's going to be some time before it does, but definitely stay tuned for fest. We'll have more to talk about then and talk about where we're at in that process of making the thing.
Chris: Yeah, no. There's already been a lot of making, and there's already been a lot of adoption I feel like. Like Jeff Gearling when we first adopted the project, I talked to him and he was like, "Yeah, I kind of just write my own tests with the certs and stuff." Oh, that's cool. That's what I would do if I didn't have this. Now he's actually starting to adopt it for some of this stuff, which is great to see.
Dylan: Yep. And to that point too, Ansible is a great way to Ansible stuff with the certs and whatnot. We actually introduced recently into Molecule the way for Molecule to call Ansible as the test structure is opposed to test infra which is the main way that you do testing. So that is a thing now for the Jeff Gearlings of the world that like to utilize Ansible as the test framework.
Chris: Yeah, that was one of my main gripes, and especially for doing the Kubernetes installs with Molecule. To use the verifier to verify everything with Ansible is super, super handy because you're literally writing your test as you're writing the actual playbook. Super fun. But this isn't a Molecule webinar. Anyways. So collections. Yes, there's many, many things going on. We're super excited about them. Lots of activity, especially in your world, more so coming to my world soon, and we're really looking forward to hearing more as time goes on. Anything else?
Dylan: Nope. Thanks for the time today, Chris. Appreciate it.
Chris: No. Thank you, Dylan. And thank you for everyone joining us. Like I said earlier, this has been recorded or is being recorded right now and will be shared as soon as I can get it shared, and we will talk to you on the next webinar. Thanks everyone.
Dylan: Bye, everyone.
Principal Product Marketing Manager, Red Hat Ansible Automation