I'm amazed that so many people thought that the right decision was to come to this one. So hope all of you like it and we're going to basically go through the process of contributing

to Fortman. What is Fortman? I'm assuming that maybe some people here don't know much about the tool and what kind of features do we need to fix. What kind of programs do we have in order to fix those things.

So before I start, this is, I just added, this is light. If you guys use Fortman in production or even in a development environment, take a picture. It's our survey and we're trying to figure out what you guys like, what you guys want

for the next versions, what are your feelings towards how we do versioning, how are your feelings towards our support on IRC, the mailing lists and so forth.

I'll just leave it there for five seconds and we can start. Now I know who actually uses Fortman. Why am I giving this talk? That's my Twitter handle.

I write software for DevOps tools, I guess. I work in Fortman proper so my work these days mostly is on Fortman Core, Fortman Docker,

which is a plugin that we're trying to make so that you guys can use containers and manage them and manage private registries. And the puppeteer part, I guess it's because I prefer puppet to other configuration management

solutions. Anyway, so if you guys don't know what Fortman is, it's a life cycle management tool. Basically, you can get an inventory of your machines and you can get your...

So Fortman takes care of provision in the instance, which means putting it up if it's virtual or discovering it if it's physical and configuring it normally with puppet. But we started to have support for SALT and we have support for reports from TEF.

And then we take care of configuring during the lifetime of that machine. We can do things like power operations, we have role-based access control for your machines.

So it's nice if you guys have to manage a large installation of machines. So Fortman loves Red Hat, I guess. What I want to mean by that is that Red Hat sponsors the project very heavily. Most of the team working on it full-time work for Red Hat and Red Hat takes it, packages

it and gives you support. It also adds a little more niceties like integrations with pulp and so forth. You can do it with the open source versions as well, but Red Hat gives you support.

These are some of the Fortman open source clients. If you guys have contacts there and you're thinking in using Fortman, then you can reach out to them. Some of them, like CERN, used to publish how they use it, their setups, which are very

interesting to see how do they make their Fortman highly available and so forth. All right, so the idea is that we're going to go through three main parts. Where, like where should you make these contributions?

How, how the process is? Lastly, I'll give you some ideas and hopefully by the end of FOSDEM and conflict management camp, we'll have one poor request by some of you. Okay, so where, who imprints?

Let's start with the most obvious one, technical contributions and how to do them. Our process is very simple. We have a public issue tracker in which you guys, so it's the URL right there, projects.fortman.org.

You guys can create issues if you use Fortman and you want to tell us that something is not working as it should or something like that, you go there and tell us. You can also, if you're trying to figure out how to contribute but you don't know

how, you go there, pick an issue and start working on it. Obviously, it can be hard if you're, and daunting if you've not worked, if it's your first contribution, so we'll go through it later in the how to contribute section.

Once you have your issue done, you go to GitHub slash the Fortman, find the project that you want to submit your issue to, your fix to, sorry, and it'll get reviewed

by someone from the team. Depending on the project, it will be one member of the Fortman team. Once you get some contributions, it will also run in Jenkins and it will, we'll go through it later, but it will run in Jenkins and it will run some tests if you make a lot

of contributions or so that we can more or less trust that you'll be sending nice code, we'll be running your tests automatically. Before that, we need to review it quickly and hack it.

Okay, so that's one part, that was it for technical contributions like really writing code in any of the projects. Something that we probably need help with is packaging.

You guys can either come up with support for other systems, right now we're only packaging in RPMs and debs, and even some plugins are not packed as debs because it's difficult in some cases.

We have a little bit of a hard time to figure out the dependencies and we have to keep up with the SELs in CentOS. If you're making contributions that have dependencies, like you're making a plugin

for Ansible and you need an Ansible gem, you have to submit a pull request there with the packaging for RPMs and debs, at least RPMs, that's the only one that we enforce, but debs are also important for us. So that's what we have right now, something that I think would be very nice, and it's

a community that we have now been targeting and maybe some of you use it, it's NixOS. If you guys can see our specs and translate them to NixOS declarations, it'll be very,

very nice. Or Arch Linux, it's pretty much what you guys want to, what you guys will think it will be useful. So audits, some of you, at least when I worked with Foreman in a production environment,

we had the security team that made sure that permissions were enforced properly, that the roles were working as people thought they were working, so something that would be useful is if you guys find errors related to permissions or security problems, either on the way that

Foreman is deployed with the installer, or either with the way Foreman actually works, you can either, if it's not very critical, you can just go to the issue tracker that

I posted before, or if it's very critical, then we have a Foreman dash security list that you should send your report to, so that it can get, so we can make a CV out

of it, and it will get fixed in time, and if it's really important, we'll probably make a minor release so that your fix can go in, but anyway, most of the team doesn't really

have a production installation with thousands of nodes and thousands of users, or dozens of users depending on your case. What I want to mean by that is that you guys are a critical part of it, and if you let us know that something is wrong, we have to take it seriously.

Okay, so plugins is another area that you guys can help with. There are a lot of plugins that do not have much users, many users, so in this case I

chose Shen and DigitalOcean are really new, and not many people are using it on production, so if you guys find problems with it, instead of swearing and throwing your computer to the floor, just tell us what's wrong, and even for the DigitalOcean plugin, for instance,

it was started by a guy who wanted to have DigitalOcean, he's not working on the project where format and DigitalOcean were used, so it's kind of abandoned, so like I said,

we'll go through means to contact us and other stuff later. Alright, there's a full list in the format.org of the plugins, and if you've made some plugin that is not in the list, it's a wiki, so we trust you, you change it, and hopefully

you'll get more users. For non-technical contributions, they're also really important, and we'll start with the relatively easiest one, being on IRC is helpful for us, really helpful.

We have like 200 to 300 people in the format channel at any time of the day, so especially during the US time zones, there's a little bit less people that are going to be able

to help, especially Pacific time, so people are constantly asking questions about failed installations, posting their logs, asking about if X use case is possible or Y use case is possible, so even if you don't even plan to start answering questions right away,

it's useful for us if you're around and someday you see that this guy commands, hey, so I want to use this format with Tiff, what kind of gotcha should I be warned for?

So just hang around, and if you see anything that you think you can answer, great. Translations, I'll go through how to translate a few strings, it's a really simple

process and it helps us a lot, so we use trans effects for this.

The way translations work, you'll see it's really, really simple to translate a few strings. We have a few languages that are almost 100% translated, like I think it's French, Spanish,

and I think it's German is the next one, it's a little slow. Here you can see, if you make an account here, you go to the organization Foreman, it's on the Foreman docs site, I'll show you that later.

Essentially you come here, if you see one language that you speak well, there are many more, there are languages that have very small translations, because maybe it's only a plugin that is translated, or it was translated only for Foreman 1.0 and

now there are many more strings. Anyway, since I speak Spanish, I'll pick that one. I clicked on the Foreman organization, then Foreman Discovery needs some help, I click

on translate, and basically you see here the strings that do not have a translation, you click on it, we have a glossary for terms, because we know that things like provisioning,

hosts, they don't translate well in some languages, so in this case our provision, it looked like it was auto provisioning, so I guess it's, okay, we save it, and

now for the next minor version, we will get that translation and put it in the package.

Also, your users do not have to use the translation that you choose, so you can have a different locality depending on the user, it's configurable. Alright, design, we don't really have people working full time on design on Foreman,

as far as I'm aware, and it's an area that doesn't have to be changing the interface of Foreman, it's made with Bootstrap, I can show you more or less how it works here,

I don't have my, that is really broken, okay, it doesn't look like that normally, but anyway, what you can see is that it's made with, I mean it's like that because that's on my external hard drive and I don't have it connected right now, but anyway, what I want to say is that it's made with Bootstrap, and also there's some workflows

that need some help, like if you've used it, you'll probably find the way we associate operating systems and provision templates a little bit complicated,

or associate roles with filters, it's complicated, you'll get it after a while, but we think that it can be improved, so if you guys are UX or UI masters, your help in that part will be really appreciated as well.

The docs, we have a huge manual right now, it's how it works, and okay, I'm going to show it, so this is basically how the foreman.org site looks now, we have some media, like articles that you guys publish, you can submit a pull request here,

and they'll get published there, and if you speak at some conference or something about Foreman, then I think this guy spoke in Linux Australia or something about Puppet and Foreman,

then we will publish it there, it's a simple process, but anyway, documentation, we make a manual per release, and basically the manual covers a lot, like absolutely anything that we can think of.

The problem here is that it is difficult to keep a manual up to date, like for instance here, it says that this feature is not there, we should wait for this feature to be completed.

So this is in a repository which is in the Foreman GitHub organization, it's theforeman.org, and it runs with Jekyll, so it's markup that is really simple,

it works with markdown I think, or GitHub flavored markdown, and yeah, so you can help us either keep this up to date, or you can think of a way of organizing this better, which there are probably many ways to organize it better, then it will be reviewed and hopefully it will get in.

For instance, the way we plug-ins normally are documented as readme in the plug-in repository, that's not very good documentation I think, so we started a manual part of the documentation in theforeman.org,

if you use any plug-in or you want to tell us, here you go. With the exception of Cattell, which they went the hard way, and they even made their own documentation site, which is really good,

because it's a very full featured plug-in for content management in Foreman. Okay, use cases is another part of Foreman that people constantly ask about,

they want to know how people are using it. We haven't started that, but if any of you are willing to do so, I guess you'll probably accept it quickly. Find some part in theforeman.org where you can write a small article about how you use Foreman,

you don't have to give us your name if it's confidential or something, just maybe share the way you're deploying it. Right now people are doing that on their blocks and we aggregate that in theforeman.org,

but that's another part of the docs that it will be nice to have. Okay, so how to actually do this? The process is really simple now, it's guided by three friends.

So Jenkins and Foreman, they basically run our CA system, which is, we run tests, we make packages, the RPMs and devs that we talked about, and run them in Vagrant,

and then we run a full set of tests that actually connect to a live Foreman instance and make sure that everything is fine. And the other one is Rubocop, if you don't use Ruby you might not know it,

but it basically checks for syntax and other minor mistakes that you might make in your code, or silent changes and so forth. Okay, so basically the process is simple as I said, you clone the repository,

you make your changes, add the changes to the commit, you make the commit, it has to be in that format, if it's not in that format Rubocop will warn you,

well not Rubocop actually, we have a Foreman robot that checks the pull requests and will check for that. That's basically linking to the redmine issue tracker that we said before, so when that's merged it's also closed in redmine.

So you do that, you create a pull request, someone will review it, someone will review it more likely if tests are passing, if not you probably want to make your tests pass first,

if the review goes well, if it's a minor change and Rubocop didn't complain and it can probably go in, if people complain about, well they didn't complain, if they suggest to you better ways of doing it, just take those into account

and you either make another pull request or force push to that branch. Just don't take the review process personally, we mostly criticize code,

we're trying not to sound harsh, so just keep that in mind. And if it's fine it'll be in, and if it's in it will be merged for a major version

if it's a big change, if it's a small change that can easily go in a minor version it will be there. A way to check for that is to go to the redmine issue that you created,

in this case 931, you go there and you see what release is your change supposed to be for. Before I forget, we've been supporting the outreach program for women for two quarters already,

so if you know someone who's studying and wants to help us build Foreman, there's a section in our site with possible projects to take, it's here,

and it basically goes through the basics of how to set up Foreman and some projects that would be interesting. Right now we have one OPW intern working on Foreman and Docker mostly.

So a few ideas that I'd like to get in, and that you guys are looking for relatively simple things to contribute.

It's a redesign of the Foreman.org in which it looks a little dated already, but it's not only that, it's that, like I said, plugins, docs, we're just having an enormous drop down where we have plugins and the manual versions, it can probably be improved if you guys want to take on it,

it's an easy way to get a first contribution if you're good with designing I guess. So docs for plugins, if you're using some plugin, like Discovery has their own docs now,

but if you're using some plugin really heavily, like Foreman Salt for instance, you might want to write about how you make Foreman work with Salt, things that would be reasonable to do with the plugin, things that are not,

maybe some files, some issues, mentioning the things that you'd like to see in the plugin in the future. The Foreman UI and the API right now, I think they are a little cryptic in terms of,

it doesn't give you good defaults if you want to create a new host or any object, it doesn't clearly tell you where you're missing or give you options,

like examples of how it should look like, if you want to help with that, that would be also very useful. Volumes and compute resources, that's a big one in my opinion, we have easy to users who want to get block device mapping,

but they don't have it because we haven't worked much in that regard yet. I've started to work a little bit on it, but it's the same for OpenStack, they want to get block device mapping, liver volumes that we have support for them, we can create virtual machines with volumes but not with pre-provisioned volumes,

so basically any work that help us introduce some storage in hosts, I think it will be highly appreciated.

The dashboard, I think when I wrote this slide, there wasn't recently a pull request with major changes to the dashboard that would allow this came, but basically it's a way to,

maybe you want to improve the way the dashboard is so that you can add some queries that you make to facts or to host and show like that. Right now it will be easier with changes that will come in soon.

That one is a little hard, if you're using compute resources, like let's say OpenStack for the sake of simplicity, in OpenStack you can go over there and see the list of images you have, the list of hosts, but if you don't have these hosts in format,

then you have to create them there and associate them. Similarly for images, you have to link your operating systems in format with images. It would be really nice if you guys figured out some way of automatically associating that.

We have a dynamic inventory for Ansible that some guy made one year ago, or more or less one year ago, I think,

and I tested it and it works with all versions, but it's now abandoned because the guy left the company where he used this, so if anyone wants to start improving how the Ansible dynamic inventory works with format,

that would be also a nice initial contribution. All right, so that was it for ideas, how to contribute, and what.

I'm about to finish just some slides about where to find this. Forman.org is where you can find most of the official information, like the projects that compose Forman and the channels and general help.

We have two user lists where you can tell us about anything. Forman Dev is mostly focused on discussions about changes that will be in Forman, how to develop it, and users.

It's for help or people just telling us that maybe Forman doesn't fit well their use case for some reason. And then, I forgot to write it, it's Forman Security, which you can send security reports there.

Then, again, the RAC channels, please hang out there. If you use a BNC, you can be there all day, and if someday you see some question or something and you work in that area,

you can help us. And that's the repository. We love new contributors. Well, thank you all for coming, and thank you especially if you made some contributions. We're in the, I don't know what's the name of the building, but it's the San Toes stand.

We hold office hours tomorrow from one to three. If you want to come by and ask us questions about Forman or you want help, we'll be there. We will also be at configuration management camp from Monday to Tuesday.

We have our own room there, so I hope to see you there if you're interested in this area. And if you don't know how to write a plugin, I'll go through that process also there. It will be more of a technical talk.

We'll go through how to write code for that. And also tomorrow I'm speaking about Forman and how are we going to manage containers.

Okay, so that's it. If you guys want some stickers, I'll be here. Do you guys have any questions or comments?