This RFC aims to target building out all the current ways hosts are ingested into Foreman and begin discussions on simplifications that can be made to existing tools and workflows. The goal is to bring both awareness and cohesion.
I may get a few or many things wrong as I have attempted to cull this information from as many sources as I could muster. Please feel free to edit or post changes and I will see that they get amended.
- Simple client workflow for users
- Simplify delivery mechanism for client tooling
- Least amount of client tools as possible
- Less duplication of workflows, more power into templates and REX
- Enable more client operating systems with less work
Hosts can be created in Foreman through multiple methods:
- Directly via API
- Secondarily via a plugins API
- Uploading facts
- Directly via the UI
This allows a number of supported integrations to create hosts via their own workflows:
- Puppetmaster uploading facts about managed puppet hosts
- subscription-manager registering to a Katello endpoint
- Ansible callback uploading facts about hosts
- Import hosts from compute resource
- Chef client fact upload
- Salt client fact upload
Advanced Client features and tools
In addition to adding a host to Foreman’s inventory, there are some advanced features and tools delivered to the community to support some workflows. They are:
- katello-host-tools: Delivers yum integration for reporting package profile and enabled repositories.
- katello-agent: deprecated. Used for basic pull based yum actions
- katello-host-tools-tracer: Provides tracer support
- foreman_scap_client: Runs Openscap scan and report upload
- katello-consumer-rpm: Handles configuration of subscription-manager and CA certificate placement
- katello-client-bootstrap: Used for migrating existing hosts into Foreman/Katello, EL focused as it uses yum/rpm/subscription-mananager under the hood
- host registration template: Ability to register an already created host with a JWT token and a server side generated template
Add a new client script named
foreman-bootstrap to be as thin a layer as possible to connect a new or existing system to Foreman and prepare it to have actions taken against it from REX or configuration management system. The connection to Foreman would depend on the users desired method, e.g:
- Registration API using JWT token
- API using username/password
- subscription-manager with username/password
- subscription-manager with activation key
- Config management fact upload
The bootstrap tool would focus on using templates available from the Foreman server to render functional scripts that can be ran on the client to enable functionality. This would centralize and re-use the hardened logic already present in the templates. Further, this would help keep the bootstrap tool thin do only the necessary auth and handshakes to connect a client back to Foreman.
This script could be delivered directly from Foreman opening it up to use across a broad array of client OSes. This would follow the model katello-client-bootstrap has today but extend out to include more operating systems with less packaging work.
Introduce foreman-host-tools for advanced client tooling
All other tooling needs for clients would be contained in a single foreman-host-tools package. The foreman-host-tools package would handle advanced functionality that is not needed to bootstrap a host to Foreman and cannot be maintained in a template. For example, yum plugins or scripts that need to exist on the client that are more easily maintained in the tools repository rather than from a generated template.
All other needed functionality for a client would be provided through the client repository. For example, tracer support.
This would be a single source code repository but allow for multiple sub-packages to allow users to install and using only advanced functionality they desire. For example, keeeping tracer as it’s own subpackage like it is today with katello-host-tools to allow users to choose if they want tracer support.
Fate of existing projects
- katello-consumer RPM would be deprecated in favor of foreman-bootstrap configuring RHSM
- katello-client-bootstrap would be turned into foreman-bootstrap and fold any additional functionality it has into templates or foreman-host-tools
- katello-host-tools would be renamed to foreman-host-tools
- foreman_scap_client would be built into foreman-host-tools