Foreman Landfill (aka "tools" or "extras") repository

problem statement

I’ve been recently pondering where we should publish packages that are related to Foreman (both operations and development) that are not specific to a given Foreman release.

A few examples of tools that I’d like to package, but have no idea where to put them:

  • obal - the packaging helper we use for RPM packaging
  • foreman-ansible-modules - the Ansible collection we maintain to talk to the Foreman API
  • apypie - the API library used by the Ansible modules


During the last meetup in the US, we came up with the idea of an “extras” repository (and called it landfill, for obvious reasons) that is not versioned (in contrast to the foreman-client repository we already have) and includes the above packages, build for at least EL7, (EL8 as soon as we can build it) and whichever Fedora we can build.

That repository can then be used by users and developers to get the tools they need without having to install them from Git.


Instead of creating a new repository, we could also package the above projects into the existing client repository. This would make the resulting builds “version specific” on paper and require the users to use the “client-nightly” repository if they need the latest and greatest bits. On the other side this would require no new setup on koji etc.

1 Like

I think links to download the latest git repo would be appropriate, why duplicate locations, with a soon to be superceded version? It would have to be manually updated by someone as well. ( True it could be automated ).

You could use this javascript snippet from the JQuery library to embed github repos into a html page:

Just my opinion.


Paul Krash

:+1: for a better place to host obal. Currently I have but it’d be nice to have this on a more official URL that others can maintain as well.

Regarding foreman-ansible-modules and apypie you could argue they’re client tools. I also like the concept of a versioned repo that we know we don’t break. Major version bumps in a nightly do feel safer. It does mean we might have to do cherry picks though. With that in mind, I’m still tempted to start them off in the client repositories because we might do breaking changes regularly. It also doesn’t require setup on koji so it’s easy to ‘go back’ and move them to the new tools repo.

Ease of use I guess.

Currently, to use foreman-ansible-modules, you need to clone the repo, install nailgun and apypie via pip (into a virtualenv or not, your choice), maybe adjust ansible.cfg and then you can use the modules. With a packaged version, the user can just yum/apt install foreman-ansible-modules and all the dependencies are also pulled in and stuff is immediately usable.

I’m not sure how this helps with the fact the users need the repo and the appropriate dependencies on the machine they want to use the tool?

Right. So do I read you right, you’d create a “landfill” repo to put obal in there, but not still stage the modules and their dependencies via the normal versioned repos?

oK, good points.

Isn’t possible to roll a room using the commands needed to clone the git
repo, and then fetch and install all the dependencies via pip?

That would remove the need to update your copy after every git repo update,
and do everything for the RHEL/Centos user.

A .Deb file could be built for Ubuntu/Debian as well.

windows and Macs, prob possible to script it, idk how atm.

Either way, making the files available from a git clone on your hosted
server of choice is a good one, I think.

Thanks for your reply!


Paul Krash 314-202-3334

Kind of. I think we can get away with putting foreman-ansible-modules in the client repos now and I might actually have a good reason. I’m really unhappy with having the Foreman callback and inventory in core Ansible because reviewing takes a long time and we need to follow their release model. That’s why I think foreman-ansible-modules might actually be a good home for them, but we do configure it by default in the Foreman Proxy Ansible module. Pulling in the client repo on a smart proxy is probably fine but an unversioned repo maybe not as much.