 It's better. Do you want to talk? Sure. Why not? Okay. Go ahead. Hello, guys. Let me introduce Ivan Neches. He'll be giving a talk about real-time system management with form and remote execution endsable. Enjoy. How are we doing? So before we start, I had a question in the morning from the very important person. It was not Tim Burke. It was my daughter that asked me where I'm going today because she got a calendar for Christmas so she knows that it's Friday today, and I'm working from home, working from home on Friday. So I need to explain that I'm going to a conference. She's four years old, so it's kind of, you know, explain what's conference. So I told her that there are a lot of people that gather or get together to kind of share experience, or if somebody works on something that might be interesting for others or, you know, works the way that others should know about, they just go there and talk. So that's what I will doing today. I will talk about the things that I'm working on, that I would like you to know about, and that's the whole purpose of this talk. So I will be talking about two related things. The first one is the remote execution. If you see remote execution, what's the first thing that comes up on your mind? When I hear remote execution, my reaction is, or something like that, because remote execution, like, there are a lot of services, a lot of projects that have the remote execution built in, but it's not a bug or it's not a feature, it's a bug. So I'm not going to talk about the remote execution vulnerabilities in Foreman. I hope we don't have any at the moment. I'm going to talk about remote execution as a feature by design that we built into the Foreman. So before we start talking about what's the remote execution capability in the Foreman project, let me briefly talk about the Foreman itself. So how many of you know what's actually Foreman? Okay. Cool. It's half, so just briefly for those that don't know, Foreman is a project that's been here for about seven years, eight years, seven years. And it started as a configuration management tool or reporting tool. There was a question in the previous talk about how you know PAPET actually run on your systems. You should use Ansible because you can't know with PAPET. So Foreman is the answer for this question for this long. So the first thing Foreman actually was able to do is show how the PAPET works or how the PAPET behaves in your infrastructure, and we started adding additional features on top of that. So right now, Foreman is able to provision your systems, including bare metal, virtual machines, or cloud instances. It's able to do configuration management, or integrating with other configuration management tools, and there is also a set of monitoring tools involved in that, in connection to the configuration management. So I will need to mention that Foreman is very extendable, and there are a lot of plugins that extend the core behavior of the Foreman. So we have many plugins regarding compute resources to plug additional resources for creating VMs on virtual platforms or cloud. We have integration with multiple configuration management besides PAPET, such as Chef, Salt, or Ansible. And we are integrating also reporting tools and many others. We have the whole page of the plugins that you can install on top of the Foreman. So today I will talk about two plugins that are in the Foreman. And before we start, this is the picture that I need always to have in my presentation. It's just the way I do presentations. So this is the architecture of the Foreman, and it will be useful to know how it works when I will be explaining the remote execution and Ansible integration inside the Foreman. So the Foreman itself is the front-end application, so UI and API that serves your request. But in order to do something, we rely on the Smartroxies, which are small services, that can run either on the same machine as the Foreman, or they can run somewhere else and they do some heavy lifting for us. For example, when we install something in the unattended fashion using the Pixie Boot, we use the Smartroxies to actually configure the TFTP. When we need to configure the DNS or DHCP in your infrastructure, we again rely on the plugin to this service to actually do that. So you install Foreman on one place and then just distribute the services where you need it. So that's all you need to know from this diagram. So there is a Foreman and multiple proxies that we rely on. So the remote execution itself is a plugin to the Foreman. When we, I have typo there, when we, so I have typo, I really like the bottom. So when we designed the remote execution capability, we were thinking about using multiple providers for that. Because not everyone actually wants to allow SSH in their infrastructure, so we are ready for adding multiple providers or different ways, actually executing commands on remote hosts. But the SSH is the first one because SSH is quite of so common that it's good to start there. Another thing that we wanted to make sure when implementing the remote execution feature in Foreman is using the concepts that are already there. Therefore, for example, we built this functionality around configuration or provisioning templates or templates in general to actually produce the scripts that you will run. We put a definition of inputs on top of that so that we can actually render nice a UI for the invocation. And we are able, once we run the job, we are able to spread the execution through multiple proxies. This might be like one use case is just all balancing the execution when there are multiple or too many hosts that one proxy couldn't handle that. The second thing is that it's not that common or there are situations that the Foreman itself can't reach to the remote host directly. And that's where the proxy comes in line. So if the Foreman can talk to the proxy and the proxy can talk to the host, you are OK. Another feature there is the, for example, control of execution so that you don't have to run everything at once. And we have some capabilities around that. So that's pretty much what I want to show in the demo itself. So that's another reason why I have the no button here because live demos are always tricky. So before any other introduction to the remote execution, I will switch my screen to actually Foreman instance. And you can see that there's something failed. And we can start looking into that. So the first thing that I would like to show is like one example of using remote execution and is the controlling the packages that you have on your system. For example, a very common use case for the remote execution is just running the YAM update on your machines when you want to update it. So I will not run the YAM update now. I have another use case and it's uninstalling Emacs from your system. The model situation here is that you have installed Emacs, you have tried out to edit your files for some time. And then you started to have the Emacs pinky, the pain in your hand. So you decided, OK, I will not do it anymore. And I just want to uninstall it from all the places that it was. So I choose the package action from the job templates. The job templates are the ones that define what remote execution action will be. So I want to uninstall it from some search that I saved before. So just to show you very quickly, this is the list of hosts that I have in my DEF CONF organization. And I've also created the Forman test bookmark that just searches some of the hosts. So that's what I, when I was talking about using the concept that's already in Forman, the bookmarking system and using it for the job invocation is one of them. So it will run on 10 hosts. And I said I want to uninstall, remove the Emacs package. So once submit. So the things actually started working. And you can see it was pretty quick because uninstalling is usually faster. When I go to the details of some of the executions, actually no package was installed there before. So I'm sure Emacs is not there. And I will not bother anymore. So that's the first use case of the remote execution. Then for our Emacs story, let's say that you then figure out that if you remap the Caps Lock to control, it's much easier to use Emacs. So you say, OK, so I will install it again, whatever. So I will try it with new keyboard layout. And maybe it will work for me better. So again, I can go. So I use the rerun button there. So everything is preset as before. But right now, I will use the install action instead of the uninstall one and still the Emacs. So again, execute now. And we'll see if there is anything working or not. When I go to the details of some of the jobs, I can see that this produces the live output of the command. I'm running on the Wi-Fi that is here. So you can imagine that it's pretty slow. So I will wait a bit. And before we continue with this, I will jump to the next part of my demo because 20 minutes is really a short time for doing this kind of presentations. So while the remote execution is running, I want to talk also about the second part of my demo, which is Ansible. And traditionally, we integrate with Puppet as the first config management tool. And it's inside the core itself. We edit Chef and Salt support via plugins. It's already a few years now. And the Ansible is the newest candidate there, or the newest plugin that we can provide. So the top of my presentation skills is this red new something that shows that it's new. So we act as an ENC, which means that we provide the data for the configuration management tool to know what actually to install on the host. So why Ansible? Because it's really popular, and we want to give the users of the foreman ability to actually use this as well similar way as they use other config management tools. We don't try to use Ansible for orchestration or provide orchestration capabilities. We look at Ansible as the configuration management tool, and we provide similar functionalities that we do with Puppet, or Chef, or Salt. So again, demo. Before we do the demo with Ansible, there is one thing with my configuration that something is broken, because the DNS that I've configured the host with doesn't work inside this environment or on Wi-Fi. So just very quickly, what can I do is first, this would run for another hour, because we try all the mirrors that are there, but I can just cancel the jobs, which would actually send the kill signal to the process itself, so you see that the script actually ended, and everything failed. So what I can do is go to the job templates that are used for templating the scripts, and I can create a new template that would just fix the resolve conf. Like, you know, I have just two minutes to do that. So let's do it quickly. The job category I will call panic mode, because that's what it is. Fix resolve conf. So in the script, I would just go and say echo name servers, 8888 resolve conf, resolve n, resolve name server. I see we have some serious sysadmins here. I'm not a sysadmin. I'm a developer, so thanks. You have a t-shirt already. So let's see. Around that, one thing that I could do is also extracting these two inputs. So instead of hard coding this here, I can do some ERB magic, which is templating language in Ruby, and I can say that I want to input DNS, which is the value. So this will be a variable that I will ask the user, and I will add the required input here, which will be called DNS. And that should be all I need to do here. So I have fixed resolve conf there when I go to run and choose again the same bookmark, DNS, I will fill in 8888, submit, and it's running again. And now it's much faster, because it's just sitting something. So the DNS would not work. I don't have enough time to rerun the install emacs again, so just trust me. And I would like two things on the form that I want to show that we can also schedule the things to the future or set the recurring logic there. Or we can set the concurrency level if you run this on 10,000 hosts or 500 hosts and running some young update on there, you might just cause denial of services in your infrastructure. So these are the capabilities that can actually help you controlling how much of the work is run at once. So in this case, we see that the things are getting distributed over time. And at the end, everything finishes again. So this is like really brief interaction to the remote execution. There are much more, or not much, but more things to show, but just to also cover the Ansible a bit. So in the Ansible, we are pretty similar, or we try to treat it similar as the Puppet. So the first thing you do with the Puppet is importing classes from your Puppet masters. And we can do a similar thing with Ansible. So here I have some Ansible configured on my Forman host. It could be either on the host or some external proxy. And when I go import from the Puppet host, I actually get new roles that are available on the Ansible, or when something changes, like in this case, I've deleted my role from the Ansible itself or the Ansible host. So I can update that, so I will just do all of them. So now I have all the roles that are available in Ansible, and I can use that. So for the message of the day role that I have, I've configured the host group that actually uses this. This is the most simple example I could come up with. So I have the message of the day role assigned to this host group, and all the hosts in my infrastructure are set to this host group. So when I go and run play Ansible roles, what it will do is actually instruct the Ansible to run the playbook. So we don't expose running playbooks directly. We went the puppet way of assigning classes to the host, so we treat the Ansible roles as the puppet classes so that it fits our workflow. So what I did when I go to the host, again, some of them, I can show that in the parameters, this is another thing that we are using both for puppet. I've configured that the message of the day should be hello, Bernou, and the template is blank. And it's not configured directly at this host, but it's actually set on per location basis. So I have the location, Bernou, and I have location in Prague, and both have different parameters for the message of the day. I can show it here. So there's hello, Bernou, and there's hello, Prague. So what it means when I go to the host, SSH to host1, it says hello, Bernou. When I go to the host8 that I have configured to be in Prague, then it says hello, Prague. So this just shows that we can feed in the values from form and to the ansible again, similar to puppet. And the last thing for my demo in this short time would be, so I heard that ansible folks like the Seiko thing. So what I will do is, in the parameters for one host, I will override the template to not be the blank one for the message of the day, but to be a cow. So I will submit, so save these changes, run ansible roles just for this one host. And once it finishes, and I SSH to the first host, voila, for those that don't see it, I think this deserves this applause. OK, so my time is over, so I'm glad that I was able to show this, because I think it's awesome. And that's really it. So what I wanted to say is introduce or introduce form and to those that don't know it, I wanted to show remote execution capabilities and ansible integration because they somehow come together. And I would like to invite you to the Forman or the Forman Dev channel on our IRC. We have our own website, you know, this thing. We have mailing lists. So we welcome you all on their places, if you are interested. And for the DevCon itself, we have the Forman booth. So if it was interesting for you to see and you want to know more, please come there. We are there the whole tomorrow, so we can show you more things from the Forman world. And there are three talks. One is about the bare metal provisioning involved in Forman. One is about OS tree in pulp. It's not directly Forman, but we integrate with pulp quite heavily for the content management. So I think it might be interesting for you as well. And there is also talk about integrating Forman and OpenStack together. So this is really all I wanted to say. And before we all go to another meeting or whatever or talks, there is place for last question. OK, I see the hand there. Yeah, so what we have in Forman is the question was if there are some metrics capabilities or seeing the trends, if I understood it correctly. So Forman does have this capability built in. And I don't have time to show it, but we have the whole demo on the booth. So yeah, we have it. So that was the last question. And I have one question for you. So I have some t-shirts here. There will be one for the help with ResolveConf. There will be one for the last question. And I have another question for you. And it's how long the Forman has been around? Eight years. Eight years. Who was the first? It was the first one. OK, so the third t-shirt goes there. And that's all from this talk. Thanks, everyone.