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
apypie - the API library used by the Ansible modules
proposal
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.
alternatives
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.
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 ).
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.
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?
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.
for a better place to host obal. Currently I have