 Hi, guys. Welcome back. I was just here, but this time I'm not giving a talk with someone. I'm handing it off to Paul, who is sort of the Ansible and OpenStack 101 talk. So if you've used Ansible or OpenStack, I'm assuming that you probably have heard of OpenStack if you've bothered to come out to this event, but maybe you don't know much about Ansible or you're just figuring out how to get started with Ansible and OpenStack together, then this is the talk for you, and Paul's kind of awesome. He works in front, and I'm going to hand it off to him, and I'm going to shut up so he has time to actually talk. Thanks, Paul. Hello, hello. Is this thing on? Yeah? Okay. So I'm going to keep this short because we're short on time. Okay. Okay. So basically, I wasn't originally scheduled to give this talk, so hopefully I can try to make it through and keep it as basic as 101 with Ansible and OpenStack. So basically, a quick thing, this is what I do. I work on the OpenStack project on the infrastructure team. I've basically been with Red Hat since 2015. I've been contributing to OpenStack since 2012, and I'm not the community Ansible architect. That's a typo. Okay. So the agenda, what we're doing here today, I'm not going to cover this because it's just basically reading. So this is basically the summary of what we're going to try and do. So why are we here? So basically, I'm hoping everybody's here because they either want to use Ansible and they want to use OpenStack, and maybe they want to use Ansible and OpenStack together. Either you don't know what Ansible it is, or you don't know what OpenStack is. I'm going to give some very basic summaries of what those tools are and provide a very simple demo, leveraging the stuff that Monty and Robin talked about in the previous talk, demoing a tool that we use in OpenStack Infra called Ansible Role Cloud Launcher. So IT is difficult. I'm sure everybody knows that. The whole concept of Ansible is Ansible makes things much easier to manage. Ansible is constructed in a way where it's very basic. It's basically a task-based execution as opposed to other tools such as Puppet, which is my background previously, which you would write in a manifest and Puppet would take this raw data in and magically mangle it together and try to optimize how to deploy it. Ansible really is first in, first out of how you write your tasks. And that can be good or bad because it could be some dangerous things that you might run into depending on what you're doing. So the concept of OpenStack is make IT less difficult by delivering resources on demand. So if people who do not use OpenStack, one of the main benefits of it is, is you can basically say to the cloud, give me something, a server with so much RAM and so on and so forth. And in theory, it should be returned back to you relatively quickly. We're talking minutes, maybe hour. Previously, data centers requesting resources from your IT like we're talking weeks, days, months, so on and so forth. But basically, clouds are difficult. And this is what hopefully some of the steps that we're going to talk about here that kind of makes them a little bit simpler. So this is what a cloud looks like. And this is probably something that goes really well with the talk that was just previously happened with Monty and Robin where Monty talked about the library called Shade, which we're going to talk about in demo today. Shade hides all that from you. It's just very simple. Give me, get, you know, post, return, so on and so forth. And Monty and the team, Advanceable, Ricky and so on and so forth, do a wonderful job writing Shade and writing Ansible modules to, as an operator or as an end user, you don't have to think about that. You just say, give me something and it should come back. So, yeah, so we basically need a tool that's flexible for all the things that we're doing here for open-sac operations. And that's simple enough to get the job done. And this is where something like Ansible really comes into play with it. So why Ansible? So anybody not used Ansible before? Just a quick raise of hands. Oh, okay, wow. Of those people that are raising their hands, how many of you want to use Ansible? Yeah, okay. So you're here to learn about it and that's great. So basically Ansible is a configuration management tool for orchestration, application development. It's basically a lot of things and it's kind of like, you know, nothing else out there in, you know, my opinion. So basically the idea of Ansible is, from my laptop, I can actually get it installed in literally a second, well, not a second, however fast my internet is, and start running it. Other tools, which, you know, I don't necessarily have to get into, but other tools sometimes require agents on the node to be pre-installed and then there's this server-client relationship that needs to be established before you can even use the configuration management. With Ansible, the only thing that you need is basically SSH. And if you've created your server appropriately with networking and SSH keys and passwords and so on have been pre-installed either via boot process or some other cloud config drive or cloud init or something like that, you can start automating that server and basically automate all the things. So Ansible is simple but flexible. So it's basically Python, all open source, no DSL, so things like Puppet where you had to express your manifest and specific ways, establish dependencies, and then when Puppet compiled it, it automatically did things. It was great, but sometimes if you re-ran that task, it wouldn't do those things in the same order and maybe expose another problem and so on. Ansible basically everything is done as a task, one after one serialized or paralyzed against multiple servers, multiple clouds. Basically uses SSH, which you can use keys, Kerberos, so on and so forth, passwords, no passwords, I recommend public keys. And it's literally, well, not literally, but it is easy to use and easy to learn. I find if you understand YAML, that's your bar of entry into Ansible. Other tools usually required you maybe to learn a programming language such as Ruby and then understand the DSL of its constructs and so on and so forth. YAML, if you use it long enough, it seems pretty simple to express and use, but that's really what you need to learn is YAML. You don't need to know Python. I mean, it helps if you know Python because you can do more things, but YAML really is the only thing that you need to know to use Ansible. Okay, so what is OpenSack? OpenSack is this massive project, basically give me resources, virtualize, bare metal. I don't necessarily have to go into the deep guts of it, but basically it's for public, private clouds, running on open APIs, shared infrastructure, rapidly changing, growing and so on. It's this massive thing, it's got bare metal. You name it, there's probably an OpenSack project for it, but it is complicated and that's where things like Monty was talking about, the library called shade, the modules that Ricky and other people at Ansible work on, try to keep that as simple for the end user or the operator to actually use. So Ansible reduces the complexity of OpenSack, but OpenSack keeps it flexible. So they kind of go hand in hand and you can see, based on what Monty was talking about, and his passion of the two topics of Ansible and OpenSack, there's really a really good path moving forward between those two projects and I don't want to say depending on each other, but there's a really good fit there between Ansible and OpenSack and operators tend to love using those two tools hand in hand. So automation for everyone, let me check the time here. So basically, we're going to talk about three groups of users. So there's the consumers, the operators and the deployers. So consumers basically build instances, connect resources with OpenSack APIs and dashboards, usually called end users. Operators, operators was something I would probably classify on myself as. We are the people that manage the cloud resources for you. So we will rack new servers to expand more compute resources, add in a set capacity for storage, so on and so forth. And then there's the deployers, those are the people that actually maintain and deploy and upgrade OpenSack over the long haul. So how can Ansible help? So basically, Ansible is easy for automation, so no need for custom code. This is where things like Shade and the modules at Monty were talking about come into play. Basically, operators are created with the same task tools and playbooks. And deployers basically Ansible is used already by many OpenSack clouds. So there's a maturity there that is somewhat backed up by the, what's it called? The OpenSack foundation does a survey every year or every six months about the project in itself. And there's one question in there they always ask of how you're deploying OpenSack, what tool you're using, and year over year. It's a really interesting metric and I couldn't find the slide in time to inject here, but basically every time it happens, Ansible just explodes more and more. So as we're moving forward, Ansible appears to be the dominant tool, at least for OpenSack that's kind of, again I don't want to say one out of the battle because who knows what the next one's going to be, but has already established itself as a clear winner. And I think that's really because it's simple to use and it's simple to use and it's simple to think about how to use in production. You can take a playbook, you can look at it, you can look at the tasks, see how they flow one to one. Other tools, you have to do this mental map in your brain for something in to something out. Okay, so enough talk, let's build something. So I think I got about 20 minutes left, does that sound a bit right? So we're going to do it live. Okay, so the scenario, this was the scenario that I was going to try and do, but we're actually only going to do parts of this because like I said, I don't have raw, I'm not an admin on the cloud that I'm doing this on, I'm a user. So there's certain things like I can't do, like I can't create a new project and I can't create a new user because I don't have admin credentials to do that. I could set up a network and a subnet, but there's actually one already set up. I'm going to add some SSH keys and I'm going to create the security groups. And then basically the building of the instance and launching the website, I'm going to use a different tool with that, which is basically node pool and I'll show you how all that works together hopefully. So live demo time, I forget what my next slide is. Okay, so let's see here. Okay, so I have a cloud, so I probably should explain a little bit of this. I have a clouds.yaml file already created, which contains my username and my password and my cloud that I'm using. The cloud that I have is basically, let me see here. So it's basically a cloud that I have at Red Hat for testing that I use and it's not secure based on that here. Okay, so this is the cloud. Has anybody not seen this before? This is the dashboard for OpenStack, so if you were an end user and not using APIs and you wanted to create yourself things in OpenStack, this is probably what you would use, minus the Red Hat branding on the top here. So right now, so basically I have an instance already running, it's called WinMill, I use that for some testing purposes. So these are the instances, volumes, and so on and so forth. What I'm going to show right now is basically access control and the reason I'm showing this is that for the purpose of this demo, imagine that this is a new cloud that we in OpenStack infra want to bring online because we're adding capacity for testing. So like Mati was saying, we have a cloud city host, we have rack space, we have internet app, we have VEX hosts, we have basically 12 regions across eight clouds across the planet all over the place. And instead of me manually going in here every time and doing this of like, oh okay, I need to make sure that all my access groups are set up to allow SSH and so on. This is how we used to do it, because every cloud provider ships something totally different for their default settings. And as you bring a new note on, you would forget this over time and you would try to SSH into the system and then you would start screaming and cursing because you're trying to figure out why there's no network connectivity and it's because well, the default group here is dropping all packets inbound and so on and so forth. So what we have is basically we have this file called cloud layouts and this is public, this is our public data that we run and it's basically the configuration for the tool called cloud launcher that Mati talked about previously and that Ricky, Ricky put your hand up, this guy right here next speaker basically wrote, it was basically his idea to do this. So the concept is we have these profiles in a profile, we have a project, basically anytime we do CI we have two tenets or I guess tenets or more, two projects, we have a project called OpenStackCI which is where we put things like mirrors for our AFS backend, so we mirror packaging, Python packages, we have a proxy now to Docker for Docker registry and for some other RDO artifacts and then we have another project called OpenStackZool and this is where we actually launch all of the VMs in this cloud or in our clouds. So again these are the security groups that I was talking about, the default one and basically what we want to do from our point of view is we want it to be open, we don't want any sort of anything blocking any traffic because well we really don't care about that, we expose these instances to testers, developers like yourself or whoever in the project and we want them to have full root access, unblock networking and so on and so forth. Again this is a key pair so we create about eight, as I say, eight public keys that get dropped in, so last one's mine, the one above that is David Trues, Ian, Ricky's is in here somewhere, is yours in here Ricky? Anyways, oh yeah there you are, right here, you're this guy. So this allows all of our infrastructure root admins to be able to SSH into these machines for troubleshooting and so on and so forth and again on certain clouds we actually do have admin permissions, I'll show that a little farther, basically we as OpenStack InfraRuna cloud is called InfraCloud and we have two regions, chocolate and strawberry, no chocolate and vanilla, soon to be strawberry and then we have a blue box cloud that we actually have admin access to and the same thing we set up some simple roles and users and so on so again I can't run these on this cloud because I'm not, I don't have admin access so anything below this line here to clouds represents to me admin tasks that require admin credentials, I didn't have time to get access to a cloud or stand up a cloud that had that but hopefully what I'm going to show and talk about really kind of expresses how this works and then lastly these are our clouds and like Monty had said before all of this is built on shade which uses something called OpenStack cloud config which is the clouds.yaml file and these are all representations of the public clouds that we have and you can see there's no user names passwords in here because this is publicly available image, public available information on our GitHub or on our Git repositories that we as in for a use to manage all of our cloud resources. So with that in mind this is my very simple it's again to save myself copy paste it has everything the same as the last except we're only going to run it on one cloud which is this cloud OS lab which is an internal cloud but at Red Hat. So before I can do that so the command that I would use is Ansible playbook. Hold on Ansible playbook of course doesn't find it so what I'm going to show you is how to actually bootstrap your Ansible book Ansible laptop here so I'm going to use something called virtual environments from Python so virtual ENV so we're just going to call this one test actually we'll call it Ansible. Okay so I've just created myself a sandbox environment in Python so basically I'm going to source that because I don't want to contaminate my laptop with dependencies. Okay so now for intensive purposes I have a straight sandbox environment so now I'm going to install Ansible which is basically pip install Ansible goes out to the web downloads it this is uh this is it so done Ansible is installed so if I then did Ansible Ansible playbook version Ansible is installed okay that's it I can now run this test well almost I actually need shade so pip install shade again publicly packaged blah blah installs downloads all the open stack libraries compiles them if needs them and done so now I can run the command and if I did it right basically I should probably do this actually before I before I run it let me show you the the playbook that's the one step that I forgot so this is our playbook this is the basic minimum that we need to tell um can anybody can everybody see that I see some people squinting no really small how do you how do you control plus let's see that we're control shift plus hey that's better right so that's basically our playbook that we're going to use to parse that YAML file and publish all of these changes to our one cloud so basically we're going to run this on local hosts implying my laptop it's going to use a connection of local which means it's not going to try to ssh back to itself otherwise I'd have to set up ssh keys to allow it to to access it gather facts well I don't need to gather any facts facts are part of ansible think of it as you know tidbits of information that imply what the operating system is running um IP addressing so on and so forth kernel version so on um we don't need that and then basically we're just saying include this default rule called role cloud launcher which is right here uh again it's public on uh git.openstack.org and it's it's basically a series of tasks that we use to create like create things in OpenStack and as an end user you don't have to worry about that because the role is already set up to do this and we try to keep it working and so on so yeah so if my demo works this is going to be a command and make sure if it doesn't work I can scoot off this gauge here because I've run out of time so basically ignore the warnings okay I'm going to make this smaller so what does it control shift minus no not control minus thank you so basically again ignore the warnings because uh I don't know what they mean no I do but we don't we don't care um so yellow implies that something's changed so you can see we've created our infra keys because it's called I don't have a little pointer here but the first line says infra root keys and that's blobbing out all the eight or ten uh keys into config drive so that when we boot an instance the instance pulls this data out of OpenStatic into the local VM and then allows the root it creates a SSH authorized file that SSH uses for root user and then basically um the green command means that it did not change but it ran successfully and it has basically wide open default security and that's because I tested this beforehand and nothing changed so if we went back to here we should now basically see under keys key pairs did I show you the before so it's created my key pair for me okay now again imagine I had admin access that allowed me to create networking or I was provisioning a new tenant for new users the whole idea is is it literally took me less than a minute to install Ansible to install uh shade it took me obviously time before this demo to express all the information in YAML which is um this file where did it go this file here so obviously this as an end user this is what you care about because this is what your cloud all your clouds are going to contain and like I said we in open stack infra leverage this because we're always bringing new clouds on and it's very simple to run and yeah and the cool thing is is if we went in here and let me see if for whatever reason I wanted to add something new so security group uh foo or goo foo and basically I'm just going to copy this is this going to work oh sorry uh two and then I did two oh well you get the idea I'm fumbling you get the idea I can modify this file rerun the command nothing's going to change in the original section it's going to add me in the new section and like I said as an operator I love this because I don't have to touch a web it's reproducible we can then take this file source it into git do code review on it and and share it between our team which is distributed um around the world uh so I think oh man I still got like 20 minutes any questions so far like feel free to interact here now okay we'll move on yeah so basically uh like nobody has to come in on saturdays or sundays or whatever ansible can just do this you can store it and get stored in configuration not to say you can't do that with other tools but like we didn't have to set up any agents on on these nodes they are in this cloud I'm sorry um tool like um like uh let's say puppet or chef or salt stack because it does not have integration with shade you would have to write all of that business logic to actually go out and do all that and you're more than happy and if you want to do that that's great because it's great experience but these are tools that you can just download today and just start using your clouds yes so the question is ansible uses ssh and what do you do if you have ansible so that's a good question because I've never used windows to do that but so basically what what ricky saying is ansible has this con construct or concept of a connection and that connection can be ssh it can be a local loopback adapter it can be the driver for windows which I again I don't know what the name is but another tool that another thing that you can do is there's the concept of a ch root so people who build images or build something create a ch root and then you can basically get into that ch root and do things in it well ansible has that ability as well so if there's um if there's something that you need to do to a remote item that ansible doesn't obviously you write the new connection for it but at the heart of it it is ssh i'm sure windows supports ssh so you should in theory be able to use ssh for it but I've not touched a windows machine in 20 15 years so unfortunately I do not know the answer to that question yes sir so the question is how does ansible compare to heat which is basically an orchestra heat is an orchestration engine within open stack so it's kind of a so my personal opinion is ansible is better than heat and the reason that ansible is better than heat is because I can very easily put ansible on my desktop or my laptop and start orchestrating things from outside the cloud so that my cloud was remote for heat to work if if I wanted to do the same demo with heat I would need heat running in this cloud and as an end user I can't install that I need to then go to my operations team or my admins and say I would like to use heat can you install heat for open stack that allows me to leverage it and there are cases where cloud providers do that and there are cases where they don't do that so the big difference from my point of view is while heat is orchestration and it probably does some different no problem different things than ansible it's all limited on the fact that you need it running in your cloud and as somebody who works on the open stack infrastructure team who uses multiple clouds around the globe that are donated to us freely we can't go back to them and say hey well thanks for the cloud by the way we need our orchestration tool in the cloud to do it it would be great if all the clouds you know did the heat across then maybe we would consider using it but ansible isn't tied to open stack in that way and it's more flexible that I can like I said I can get it on this laptop and start using it heat there's an install dependency issue that needs to be addressed so hopefully that answers your question any other questions and I'll keep going yes sir revert that change right so the question is does ansible offer us some sort of a state engine to ensure that your your change on the remote node is always that change so yes so um it does but not inherent like you have to express that sometimes in your playbook so something like puppet where you would always say this file has to exist with this permission and every time puppet ran it would go and check that file to make sure it run well ansible you could in theory bypass that step depending on previous check conditions so if you write your playbook to always say this file needs to be created file a needs to be created ensure file a has permission x y z and so on and so forth ansible will allow you to enforce those states but because ansible is so freely intact task driven you can actually run ansible with only certain parts of a playbook it's it's something called tags or you can only include a specific portion of a playbook and that's where I say it kind of gets dangerous because you can bypass parts of your installs depending on maybe you want to make things faster and so on so yes ansible will enforce those things if you remote it if I if I went into this cloud right now and I deleted this key for info root and then I reran it it'll create it again for me yes you need yes so yes ansible always has to run it's not like a persistent demon that's running all the time and monitoring your file system yes sorry can you say that again can you run ansible in no op mode yes most certainly you can so there's a no op flag it will show you what's being run and so on it's actually a good I think that's what we use in testing for some of our playbooks we do a very simple no op mode just to make sure that ansible compiles and that the yaml is in the proper format it has four spaces instead of four tabs so yes there is a no op ability in ansible ansible playbook so okay so I think I mean I don't have much more here so so basically what I wanted to say was one of the use cases that we in OpenStack use is the something called Zool which I believe there's going to be a lightning talk are we done oh so I think Clint might be talking about Zool very shortly here so Zool is a project driven by OpenStack Infra which ultimately we're trying to everybody people know what Jenkins is yes Jenkins CI so we have taken Jenkins out of our system and we've replaced it with ansible 100% ansible so now we're actually driving tests with ansible and it's a great way because a it's super cool because you know it's super fast but it really is a great like task engine task executor and we don't necessarily need to rewrite that from scratch we can go to the community use something like ansible and then we as OpenStack only have to focus on the Zool part about writing the Zool code we we pass that to ansible to do all the testing of the playbook yes a schedule for Zool oh a schedule oh sorry scheduler yes so Zool okay I just got told I'm getting kicked off the stage but yes there is a scheduler there's basically there's two concepts Zool schedules things and then we have a Zool executor which runs the ansible playbooks so I can talk more about it afterwards but I really am talking into another presentation that's going to be coming about it but it the concept is Zool grabs all the information from Git we then pass it to our executor which is basically a wrapper to ansible ansible that triggers everything into the remote node and we deploy Git repos and then we start running tests and so on and so forth so I'm I'm that's the super high level and I'm happy to go into more depth with it and show show logs and so on and then basically the last one I know is basically ansible open stack which is a community and open stack which is leveraging ansible big time and then these are some projects in open stack cola by frost which you heard about earlier earlier Ursula is an IBM project and then there's some ansible open stack security and how to get started basically read the manual there's these perfectly awesome docs at docs.ansible.org and then pound ansible on free node for all your ansibles and that's it so Ricky you're up so thank you