 How are y'all doing? Is this the first Singapore meetup? Yes. Right on. Good turnout for the first Singapore meetup. So I run the San Francisco meetup myself, co-organizing it with Greg, and then one other individual. I think on average we get about 30 people. This is a pretty good turnout for our first meetup. Could it have swallowed you? So, we've had more people come in earlier than what we had. So show of hands again how many use Ansible in production today. All right. How many of you are here to learn more about Ansible to kind of hear about it? Show of hands. Okay. And then, so a quick shout out from my understanding, Ansible 1.9 users. Hands up. Okay. 2.0. 2.1. All right. No 2.1s. Anything less than 1.9? No? Good if you want to borrow my story. That's fine. It's all good. Okay. Cool. So, I'm not boring you with slides at all today. I'm an engineer, just like all the rest of you. I hate slides, so I'm not going to bore you with them. I'm only using them to keep me on track. I'm going to talk about the Ansible roadmap with you all and then talk about a cool new project that we launched last week as well. And then, I want to keep this interactive. So feel free to stop me mid-sentence if you want to. If you guys have any questions or just common general use case type questions of Ansible, feel free to ask me. I'll talk for maybe 45 minutes and then we can see how long that goes based on participation from you guys and then kind of go on from there. So with that, to level-set things, I'll talk about my past role. So before I joined Ansible a year ago, I was actually in your seat. My whole infrastructure was run with Ansible. It was a large SAS application, an APM application. I was the first ops engineer there. When I joined, we had no automation, no configuration management whatsoever. And Ansible was incepted around the same time that I joined my last job. So jumped right into using Ansible and we deployed our application from eight hours down to five minutes in a day's time of writing our first playbook. And then the rest is history. Now I work for Ansible, loving every bit of it. So two roles for me, one tech evangelist. So I go out and preach the word of Ansible and get more people into the community. And then on the other side, I'm a product manager that handles integrations with Ansible Tower as well as getting more ISVs or software vendors to write modules for Ansible. So everybody has more to write for playbooks. So that all being said, first we're going to cover Ansible 2.1 and what we launched in terms of modules for 2.1. Then we'll talk about what's coming in 2.2. And then between those I'll talk about that new product. Sound good? Cool. So Ansible 2.1, the huge release for 2.1 is we're extending outside of just system automation. How many of you actually know that we do network automation now? Show of hands. All right. So for the network side of the house, we're one of the only vendors, us being Red Hat, that actually automate Cisco devices. We automate Arista network devices. We automate Juniper devices. We're working on automating OpenSwitch. Just basically anything that is a network hardware device, you can write a playbook and automate those, which is unheard of outside of the vendor themselves that make that piece of network hardware. It's been really cool. It's been an awesome story for us. We actually have two network engineers now. FullFledge has been in networking their whole careers that are writing these modules for you to use to automate network systems. So we're super excited about that effort that we put into it. We've worked very closely with all these vendors. And all of these vendors are actually giving talks about using Ansible. And they're actually working with their customers to use Ansible as the deployment mechanism for their switches, for their routers. Pretty unheard of, but it's kind of showing the change of technology and the change of software, how we're all just kind of getting along now as opposed to competing and clashing heads, right? And it shows that open source really is the driver of that. And Ansible has been that mechanism for a lot of different companies because of its modular state. Also in 2.1, we launched full Windows support. So we're out of beta now. We feel fairly confident in what the capabilities of Windows are today when it comes to Ansible. Everything is PowerShell 3 driven over WinRM. The old days of Ansible, it used to be a Python environment in Windows. We all know how much of a pain in the butt that is. No more. So everything is PowerShell 3. We also have full support of local users on systems. Domain users are supported as well, Kerberos and ADOF and NTLM. So we're working very much on improving Windows continually with that. We actually have a full-time Windows development engineer working on Ansible Core and we'll talk about more what he's doing for the 2.2 timeframe. Docker. We made some changes to the Docker container as well as Docker image modules. We also introduced the Docker image facts module to scan containers for information associated to the container itself. And then we created a module called Docker Service. Docker Service utilizes the Docker compose YAML format, which looks pretty much like a playbook if you look at it closely, to start, stop, and scale multi-container services. And then Azure, obviously with the Red Hat Microsoft announcement around Azure, we kind of piggybacked off of that, but also we were doing our own thing in the background at the same time to build out more support in the Azure cloud. So we increased our support for managing virtual machines in Azure, the ability to manage virtual networks, network interfaces, public IP management, subnets and VPCs, virtual network interfaces, and storage and security groups, all in the 2.1 release. So it was pretty exciting stuff. 2.0, I don't know if most of you know or not, that was a huge re-architecture change for Ansible and how the core engine works. So our huge focus for 2.1 was the modules. Give more love to modules, get Windows out of beta, get network out of the test setup that it was in, and actually ship it. So we're super excited. 2.1 came out three weeks ago, I want to say now. So right when I started my trip. So encourage all of you to get upgraded to 2.1. There's a lot of great stuff to be had with 2.1. Definitely some bug fixes from 2.0. A lot of changes from 1.9. So give it a try, we'd love your feedback and pull requests are more than welcome to with any new modules that you guys can think of for the 2.2 and onward time frame. So pluring of on, any questions about 2.1? Yes? Any plans of making the group bars and home bars continue to work? Configurable, how? Because basically I want to organize the directories and I'm forced of having these group bars. Okay, so you're wanting to, you're wanting to manage how Ansible reads those directories. Okay. Understood, all right. Not 100% sure if that's a route that we're going to be taking. But I will follow up on that for you. I know we are making changes to roles in the future. One of the things I was going to cover for 2.2. What that structure is and how we're handling variables may have some introduction to how group bars and host bars are managed and utilized. But I'm not 100% sure about that hierarchical view. What do you want to do with it? Do you want to move the files? Or do you want to store it in a different medium? Because if I'm not wrong, that director is executable the same way as the inventory file. So you can literally have a proxy there if you want to read out databases or something else. Well, my use cases are just simple. Just manage it in different directors. Because there are a lot of directors also that are configurable. But how come these two are not configurable? And a sim link alone can solve your problem. Well, that's what I do now. But it's better if minimized or no sim link at all. I'll definitely have to follow up on that for you. Because I'm not sure. We haven't broached that at all in community discussions. But it never hurts to ask. It might just be something that comes later for sure. With that, there's a hat for you up here for asking a question. If you guys ask me questions, I've got cool stuff that I brought along with me from the US. There's a lot of stuff. Don't stop asking. Yes, sir? Currently, other automation tools like copper and chip, user programming language, you take chip, use Ruby, and copper, use Python. So you guys, for example, let's use shell. Are there any plans in the future? Are you going to use some constant program tools to adopt? Also, we use Python as our language for the actual engine. All modules are preferred to be written in Python. I mean, you can actually write them in any language. And then from a syntax perspective, the playbook will continue to be YAML-based. The whole point that we go with with Dansible is the fact that it's human readable and simple to write playbooks. So you don't have that crazy structure like you do with a public manifest, right? So I don't see that changing anytime in the future. But to write your own module, I mean, you can put it in any language you want to. And then the code itself is all Python-based. So definitely take a look at that for sure. Outside of that, you can write plugins that coincide with playbooks. I've seen people write those in groupie code. I myself have written them in Python. I had a team member that wrote one in Java. I mean, that's really up to you how you want to write anything to attach to Ansible. Because each organization has their own standards, right? In what way? Certain people say that they won't adopt Ruby. They won't adopt code. They use only Python. Some people will not. Yeah, I mean, from our perspective, it's whatever you want to write a module in. We don't care. If you're going to commit it to Core for other people to use, then that's when we care and we ask you to write it in Python or PowerShell for Windows. Outside of that, you can write it in whatever language you choose. There's even examples how to write them in Bash. There are. Is that a requirement for the extras modules? Yes. Yes. Anything that's committed to us is required. Just to clarify, in Windows, you actually build up PowerShell and not on Python? It's correct. In Windows, it's PowerShell only. No Python. It used to be Python? Right. Not anymore? Yeah. Speaking of Windows, just a few months ago, I was looking at it based on the version 2.001, I think. Yeah. My use case was about, actually, to get inventory on the software installed on Windows workstations. So because, basically, the main intention is to monitor the licenses, which, basically, I need to know exactly the different versions and different software installed in different workstations. Yeah. And I found out that from this PowerShell, it's very basic. So, because a while ago, you mentioned about support of... Yes. Yes. 2.1. How... What's this app? It's basically... Because I haven't seen the latest... Fair enough. So, I'll say in 2.1, definitely still not quite there yet. But we'll talk again when I get to 2.2. So, stay tuned. Yes. Why did you guys move to PowerShell and not from Python? Well, because PowerShell is on all of the systems, right? When it comes to Windows, PowerShell 3 exists on most Windows systems to date, and that is the preferred method of management when it comes to Windows. Installing Python is just like asking a Windows admin to install Java, right? It's kind of... It's almost pulling teeth out to get a Windows admin to install anything other than what is a Windows thing. But that could be a free given to any system, right? That's true. So, why only specifically Windows? Basically, for Linux, like Bash, or other scripts? Well, so from the Linux side of the house, it just needs Python. So, all systems technically have Python on them now. We're going with the lowest common denominator of a automation language that can be our transport mechanism. And those are the two lowest common denominators on both of those system architectures. There's about 107? Right now, it's Python 2.4. So, it's a great point. So, to allow Ansible to manage a host, it's 2.4. We're going to be changing that in the future, which I'll talk about in the 2.2 time frame. Yes? So, there will be a lot of incompatible issues, because like 2.1 actually we encounter the become user. It's slightly changed. We have to rewrite a lot of playbooks because of that. Any particular reason why the become user changes? Because of Windows. Because that whole, right? So, we're all used to Pseudo, right? Yeah. And Pseudo doesn't exist in the Windows world, because they're back-asswords in Windows. I'm not a Windows fan, by the way, so I will bash it. Anyways, we've got the Windows users that are used to become and become user and become method. So, in 2.1 it isn't fail-hard. There are some bugs associated to it, obviously, but either way eventually, it's going to be a hard fail. We're just deprecating Pseudo in place of that become declarative, more or less. Yes? Sorry, I know that as you mentioned you're not a big fan of Windows, but I've worked with a financial institution where I have an all-in-all service of Windows servers. I will not be working there. And one of the things which I'm working for is a good deployment mechanism. I was checking out a few months ago and you know the Windows full support was available. How committed would you guys be in terms of Windows support moving forward? You mentioned that 2.2 would be, you know, more extensive and more specifically in terms of MSPills as old as it is, but how much do you think it would support that? So, you know, we're touching a lot about on 2.2, so I'm going to skip the cool new tool announcement and jump right to 2.2. And to talk about Windows, our focus of Windows is to get full parity with Linux. We are 100% committed to Windows. So that Windows engineer his full-time job right now is to rewrite a whole PowerShell module API. So it's easier to just tack on new PowerShell modules. So another thing that we're working with for Windows is we're going to be providing a WinShell and a WinCommand module set. So on the Linux side of that we have Shell and Command to execute command, so we're going to provide those for Windows. We're also building out environment variables for Windows. Asynchronous tasks we're going to provide for Windows management as well. And then pipelines. We're going to handle that within Windows as well. So we're fully invested in it because we're basically the only ones out there that can really deploy and automate Windows to its full extent. Yeah, fine. I'll probably speak to you all. Yeah, definitely. Microsoft also launched an automation tool for automating the entire products. The free that too, they gave free as well. Are you talking about SCCM or SCCM? It's a new product. So we are using it actually. Does it work in well? Yeah. Now when you do your patching Windows patching because we moved out from BMC to Microsoft, I forgot the name. If you remember, I'm interested I'd like to hear the name of it and I'll Google it myself too. You had a question? It just came recently. Like within the past month? Microsoft is going to each organization and they are having the product. So it's free. Yeah, I'll look that up for sure. Is there any support for Hyper B? So we're definitely thinking about that. Not in the 2-2 time frame but we're thinking even for it we're going to definitely support Hyper B for sure. Do you have any advice for those who are using Hyper B now? You know, I was Googling it the other day to see if anybody's doing that and I don't see anything. So either a lot of people aren't managing Hyper B with Ansible or they just kept it internal and haven't committed anything and haven't blogged about it because honestly I can't find anything and I don't hear anything in IRC about it either that I recall. I would guess the strategy of putting something in between like a cloud stack or a cloud management platform that then manages Hyper B as a virtualizer so you're talking to an API that is cloud orchestration not VM orchestration. On that point any questions about coming for Clicker? For Clicker? Not that I can recall but I'll definitely look into that afterwards. In terms of containers you mentioned I see a lot of Docker what about the other container in time environments such as the application from there? Definitely. So to jump back really quick we announced last week a cool new tool Ansible container who here has heard about Ansible container one person and kind of use Red Hat's marketing vehicle as well. You need to use Red Hat's marketing vehicle. So Ansible container was opened last week that is going to be our way to drive the container initiative. So right now with Ansible container you can use a single play book and automatically create a Docker container. OCI initiative everything else will go through that process as well. Right now Docker is the big one out there everybody's using it so that's why we tackled that one first. It was also a realization for us to see that that Docker compose file was literally very close to a playbook. So we're leveraging a module that transforms a playbook into an actual Docker file. So how does that compare to like things like machine D, system D itself and things like format. So like standing up to show the difference. Definitely a difference because you're writing a playbook so that same playbook that you wrote to deploy on a cloud instance or on a bare metal system now you can use that playbook to automatically create a container and then ship it is a command that comes with Ansible container to deploy directly into OpenShift or Kubernetes. And then we're also adding multiple platforms and support for that as well. So we're super excited because there's always been a disconnect of how you easily build a container. So we're taking the playbook and making it the mechanism to build that container now. So as I mentioned we opened it last week. If you go to github.com slash ansible slash ansible dash container you can see the code there. Give it a try. We would love the feedback on that because we want more users start using it like Ansible was used because the more community members the only it's just going to keep getting better and better. So definitely give it a try and let us know what you think and start using Ansible container. Question? Yes. How does Spark use the integration of Ansible to cloud platforms right now? It is in process. That's about all I can say right now. We're still working out internally what those integrations are going to look like but obviously there's going to be some integrations. Right now what you can do just out of the box with CloudForms you can have CloudForms call back URL within tower effectively to drive automation. Outside of that what we're actually going to do between two products we're still thinking about internally how we're going to do that. Yes, because the new version of CloudForms which is 4.1 I can see that the configuration management is now supporting 4.1 and Ansible tower. We assume that it supports 4.1 open source but red that says that it's red that's like the 4.1 open source. So I don't know if the Ansible will also be supporting the open source. So the route that we're going to take from a product perspective will always be tower as a product because core doesn't have it doesn't have a simple enough API structure to just plug into other systems while tower has that. So that's the reason why you would see tower in the product and not core in the product. And then the same thing goes for satellite or anything else it will always be with tower. It's just kind of like what I do with all of our partners. I work tower into the story as opposed to core just because it's simpler to develop against. There are some overlap between the satellite and Ansible in the configuration management. What's the roadmap going on? Do you want to pause on the satellite and go with the Ansible? Satellite will continue down its path and Ansible will continue down a similar path. Basically us as Ansible we always have customers that run Ansible and the other tools. We never tell them to rip out the other tools and just go with Ansible. You can run them side by side and we're totally cool with that. So it's that same approach that we're going to do with Red Hat. We want to do what they want to do. We don't want to kind of dictate them this is the way to do it through Ansible. We're obviously going to keep the puppet stuff in there and then Ansible will just come along for the ride as well for the new customers that want to utilize something. Easier. Yes? Any plan to extend support and automatic provisioning of their metal servers? Idea for a very long time. I remember we first talked about that in 1.4 if I recall correctly. Community-wise we kind of just halted that discussion because Cobbler, Mike Dahon created Ansible. He also created Cobbler and he basically said I don't want to do this again. So I'm going to say that I thought about it because I have kind of that same idea as he does. Because Ansible is a tool that can tell other tools to handle provisioning nothing saying that a Cobbler module could come out and tell Cobbler to manage provisioning. There's a vendor in San Diego that does some pretty cool stuff about system provisioning that I'm working with right now that spans multiple types of hardware products. So we're going to work with them more. But yeah, I don't see right now any time in the near future Ansible core by itself doing system provisioning. Do you have Roadmap for Tower? I do have Roadmap for Tower. Are you all interested in carrying Tower Roadmap at the end? I'll talk about it for like 5 minutes at the end, I promise. So one thing about Meetup is we try to keep it as less product centric, more community focused. At least at my San Francisco Meetup I tried to. You in the back and then you over here. Would there be a difference from a point in view for Ansible? So in 2-2 we are definitely working on Ansible Vault. I'm trying to find my slide on that. For the last 30 minutes. Oh well. I'll do that. So from a platform enhancement standpoint when it comes to Vault we're going to be able to provide the ability to work with multiple Vault password files at one time and multiple Vault files per playbook run. So we're making those improvements. We're providing availability to all of that via filters as well. And then per variable quality is going to come as well as a part of the platform enhancements. For encryption wise I think we're talking about increasing encryption to what? I'm not 100% sure. But the cool thing all of these things that I'm speaking to when it comes to Roadmap by the way is open and available on our repo. So just go to the repo there's a document called Roadmap if you open it. It's everything that we're talking about here today and a lot more detail in some cases too. So definitely go take a look at it. We spent about 2 weeks on building that for the community so look at it. When it comes to the rest of the platform enhancements a huge bit of work that we're working on in 2.2 is Python 3 migration. We're going to actually make a switch to Python 3 being the engine runner of choice mostly because Red Hat 8 is moving to Python 3 and a lot of systems like Python 3 by default. So as such 2.4 is kind of going to phase out and it's going to move to a 2.6 or 2.7 minimum. So the work has already begun with that platform migration. We're just going to go in full force with it for the 2.2 time frame and probably roll it out in 2.3 maybe 2.4. So it's going to be a gradual change but that's kind of what we're working on. So would that mean the end points would also be a part of that? And the managed nodes will need to upgrade? Yes. That is kind of going to be the expectation that's why it's not going to be a overnight change. We're going to do a gradual change. It's kind of like how we've been handling playbook deprecations. It'll be the same thing. We'll start warning ahead of time saying hey we're going to be requiring 2.6 or 2.7 now think about what it's going to take to upgrade those. I mean it's not happening any time soon so don't stress but it's eventually going to come. Along with that we're going to make connection handling improvements I mentioned the changes to roles we're working on a lot of things when it comes to roles and then inventory handling is changing so I'm going to assume stuff is probably going to change with variable structures because those are directly tied to inventory and how the inventory is handled. I'll ask in community what we're thinking about and probably get that filtered up to the roadmap so people can view that. You still have a question I think? Yeah I guess it's probably a good segue after the future stuff but where do you see the management stuff going with other tools? I know there's a bit of Kubernetes work that's going to be there obviously where the things fit in with OpenShift and now that Chef's starting to get into the space with any tools. Yeah I mean Chef did, Puppet made their announcement about 2 months ago I think for us we're definitely there as well and Ansible Container is the beginning of that so along with Ansible Container modules for Kubernetes and modules for OpenShift we're just going to keep improving on those. We partner very well with Google I have a weekly meeting with Google actually about not only Kubernetes but we talk GCE as well so we're making improvements there and then just because of Kubernetes I mean OpenShift right is Kubernetes so we're very close to the OpenShift team I mean OpenShift is installed with Ansible so they're huge fans of Ansible and we're huge fans of them I mean I'm a Kubernetes fanboy by just default so I'm pushing on that train as hard as I can because I think there's a lot of room for growth there that being said we're talking about a mess of a story we're starting to start crafting that and then I'm a huge HashiCorp fan so I'm talking to HashiCorp and we're talking about you know a Terraform Console HashiCorp Vault Story kind of thing so definitely the container space is interesting to us and we want to be involved with it and just because everybody that uses Ansible is involved in containers in some sort so I mean it just kind of comes along with it that's the beauty of Ansible it's always been community driven rather than a company that oversees it we just only made that company three years ago now right there seems to be a lot of people in terms of do you think there's going to be a sweet spot that finds its way in there as the management you know the overlap can be seen everywhere there's overlap with satellite there's overlap with CloudForms there's overlap with OpenShift the way that we think about it is because Ansible can manage all of those services as well as manage the tools that manage those services you pick the tool or the instrument that does the job best for you as the user you state that it's only the Ansible way the Ansible way to us is enabling you the users an easier way to manage those tools that you choose to purchase or utilize so when it comes to manage IQ slash CloudForms you utilize Ansible to manage manage IQ slash CloudForms as opposed to logging into it spinning up the instances and then have it go to Ansible you can definitely have that workflow happen but why not just have a playbook that manages the whole workflow itself and then just log into Tower at the press of the button and it does everything automatically you know that's the story that we're trying to craft Ansible is that tool that manages everything we've got a really cool graphic on Red Hat's website about Tower being that tool that manages all the tools in the tool chain and that's really how we've always thought Ansible to be and why Tower is that framework to do that let's see so networking we're definitely building on networking more so I mentioned Open V-Switch we're going to do routing support GoVGP and Quigga and then VMware is getting love they're actually going to become a first class citizen and Ansible support the hardware side as well as the network side so more to be seen there and then other network vendors that we're not allowed to talk about at all and let's see so Tower Tower 3.0 we're doing just a user experience refresh so that's coming question so other than being able to manage Open Flow is there any other SDN providers that you guys will be working with are you also disclosed? no yes we are you mentioned about the support on networking modules so you're saying that N211 these networking modules Cisco, JunoS all of those N211 yes that's all N211 and N22 we're switching over to SDNs because on the hardware side of the house most of them are covered in N211 we're obviously going to keep building off of that in N22 but we're going to be focusing on SDNs in N22 as well those are Open V-Switch yep that could be under 2.2 2.2 correct do you think the SSH is connected or is it directly the HPTP over to their APIs that's how we are communicating but the legacy devices is over SSH or not? so the legacy devices most of them are over I forget they've been manageable most of them are Nexus OS and the newer stuff that most people are on nowadays so I think the legacy devices are out as far as I remember I might not be 100% I'm not a network guy and I will never claim to be one personally so what's the new watch sorry who? New watch? the name doesn't ring a bell but even if it was I can talk about it there was a new watch New Watch bought by Alcatel yeah yeah I can talk about the support go for it sorry I'm the latest release the tarp home 4.1 and that's going to support SDN new watches plug in natively in CloudForms as well so they've been a good partner of ours in CloudForms for a while but now they're going to be native in the actual UI which is great news for us in general cause you can cause then you can handle you can call that from Ansible it will be back to you all calling both ways yep this is a high level question probably because this is completely a configuration management and OS system level is there any plan kind of a process level of consideration where it interacts with the kind of application level and people with like integration with the service now or integration with like a that welcome to Ansible my friend because it is not only just config management you can actually do all of that so Ansible it has four use cases that configuration management is just one of the four we do application deployments so me personally I did all my app deployments after that application deployment occurred I also added it to monitoring and then also added it to pagerduty and paindom as well I actually wrote those two modules myself and then added it into load balancers so after software layer of the load balancer I added into service that's the power of Ansible by itself it's just not system level config management it does a lot of other stuff service now specifically we have an integration with service now and tower so you can kick off jobs to tower via service now and then service now could also be utilized as a dynamic inventory potentially to pull systems out and do automation against them it can be done welcome to Ansible you're in good group here so how easy are the three of the kids doing to get service now with Ansible like if it's something I can do we can invite people or something definitely get in contact with your Red Hat Rep and then they can get you through the process so what that looks like for sure yes actually just a request for documentation the support of Redis because it's there but then I haven't seen that documentation so for you mean Ansible utilizing Redis yes okay it's a key value install yeah okay noted I will I don't know how much more the answers to that honestly I agree with you the support is there it's just a matter of getting down and writing the docs that's the thing about one pitch I can make about the community one thing that we always say is even if you just commit to docs you're you're involved in the community and you're a contributor there is a lot of room for growth for docs so the Redis key value store and how Ansible can utilize that only recently have we focused on the developer guidelines for Ansible that's been lacking for the past four years and that's because one person in the community stood up and said you know what we need these let's stop pussy-footing around about this and get that in so we actually finally did it so it's just a matter of where do people want to focus and honestly a lot of people just want to write code for Ansible and write modules because that's the cool thing but there is a lot of room for docs as well so if you guys want to write docs for us we would love just to commit some docs as well so definitely a topic as well I know that it's one of the criticisms that a lot of people have is the label of tests on core modules is that on the roadmap yeah part of that came with the architecture change now that 2.0 has changed we have the way to facilitate a lot of those testings and we're doing a heavy focus on what is a core module versus what's an extras module and how we facilitate those changes and testing paradigms so a lot is coming in the future with that for sure it won't be perfect because testing is never perfect obviously but it definitely is coming so back to tower 3 we're changing permissions a bit and how we handle permissions because it's kind of a pain right now integrated notifications are coming and tower.3 and runtime job configuration is coming on and finally integrations with red hat products are coming in tower 3 as a dynamic and mentor influence there are discussions but no time frame I mean obviously so red hat opens everything right tower is no different when to be determined that's all I got guys I mean honestly I went through our 6 month roadmap with you for right now the one thing I know it sucks for this side of the globe but we have multiple meetings a week however it happens at like 2am your time the one thing I can say about those meetings is every single one of those meetings that happen over chat are recorded so you can look via another repo it's called community repo each one of those meetings are linked to and you can see what we discussed you'll see me a lot in there I'm Thamos on IRC I'm actually Thamos everywhere so get a twitter IRC we're very vocal we're very passionate community and just because all of you are part of the Ansible community that only makes it better so being involved on the other side of the globe is just as easy as signing in and taking a look at what we discussed and contributing to pull requests an issue that we may have open and we're very accepting of all of them I would love to get more involvement because I would love to see an Ansible Fest here in APAC gives me another reason to come back to the region and actually bring my wife with me this time feature feature the standard output when running Ansible will be sent to XMPP the chat room so that is definitely so XMPP I'm wondering do we have a module for that? yes but that's going to configure plus I'm trying to say the output you'll see from this send it out to chat room I'm definitely doing what tower because all of that is handled in multiple API endpoints it's not as easy to manage with Ansible by itself unless somebody writes a callback plugin that can do that so I'll definitely add that as feature request for core but I can tell you I'm definitely doing that with tower and Ansible can be exposed to as an API or like an JSON or like some other format well it already is I'm not talking about just talking about JSON so it already is exposed to JSON so it's just a matter of writing a plugin that can transport that JSON to to another chat service more or less any other questions? comments? concerns? writes? cool so did you guys find this first meetup a good level setter I would say for the future how often are you planning on doing I guess it depends on what we can fit them with and also in terms of venue so hopefully Redis is going to be nice to us and let us sort of reconvene so what do you guys do? and also I mean it's up to you guys what you want to fill it with we have opportunity to bring as I mentioned if we don't have anybody physically speaking we can bring in somebody who can do it remotely other than the states from Europe but even better if you have support to share go for it you have some volunteers do you want to use the story or do you talk for often or something if you make up four of those in a couple months or something every day just tell your story about what you do and how you utilize Ansible I'm a firm believer of something I do maybe something you haven't thought of and vice versa something you do I never would have thought of and I've been using this for four years now so there's always two heads are better than one and the fact that there's 40 to 50 plus of us in here I mean it just screams that there's an idea out there that somebody hasn't thought of share your story and it always makes a great meetup why did you choose Ansible when you started I chose Ansible because it goes to those foreign use cases back when I used them Puppet and Chef definitely didn't do application deployment and I needed a tool that handled that deployment and Ansible fit the bill with me I was also a huge fan of Cobbler so it kind of came along with it so that's ultimately why we chose Ansible and it was also a lot easier to manage I didn't have to install a Puppet server I didn't have to install a Chef server I just pip installed Ansible on my laptop did you know about Hudson or Jenkins then? oh yeah I did I'm a huge fan but those tools are great but they're good build tools they're good at managing builds having them manage deployments yeah back then Jenkins didn't even do deployment I mean that's sort of predating that I mean all these are decent at it now but because I had the same thing and Chef I was looking at Puppet and I was it was frustrating that I had to spend a week to deploy the first machine literally I mean I wrote a playbook, it installed it out of an RPM repo, installed my app because I had the same problem and that app deployment primarily just instantiating the machine and it took me 90 minutes from really looking at things for me Ansible was good because Python was already there and there was no Chef server or Puppet server installed my first stumbling block came when I started playing with CoreOS because it didn't have Python so it installed this mini Python but you can't boost Python with Ansible yeah well yeah I actually have so I'm on my plane flying up from Australia to here I wrote, I started writing a playbook to bootstrap of Fedora workstation because I'm actually migrating off of that monstrosity right there moving completely over to Fedora my playbook is going to bootstrap workstation get Python 2 installed on it then install all my baseline packages for me locally and then I'm going to be committing a role to Galaxy that is developer centric around Ansible and the Docker paradigm so keep an eye out for that definitely but yeah that's what I'm working on in regards to CoreOS there is also from Nathan Leclerc I think from Docker he has this blog article where he creates an Ansible container then he gives it like a privileged role and in that container he runs the whole playbook thing on CoreOS to deploy CoreOS is all continuous right so you have to fiddle with the CoreOS itself yeah so he brings up a good point Docker.com all Ansible they're huge fans of Ansible even though they won't say it Ansible is now a red hot company