Katello on Existing Foreman¶

Summary¶

Goals:

1. I am a user and I want to install Katello on my existing production Foreman.
2. I am Foreman developer, and I want to add Katello to my development environment.

Targeted Release¶

Targeted Persona¶

Samuel - System Engineer - production Foreman
Daniel - Developer - development environment

Discovery / Research¶

Data -- bbuckingham/sloranz¶

Databases

Katello currently only tests and supports Postgres.

Issues:

1. Do we add MySQL support?

Backends

Katello has three main backends that store data: Pulp, Candlepin and Elasticsearch. Some Katello objects has corresponding objects in one or all backends.

Issues:

1. Do we remove the use of ES? Some work has already gone into investigating performance differences and in to converting entities away from ES. The question then is, do we remove ES before we allow Katello to be added to an existing Foreman?
2. Existing Organizations need to be created in Candlepin
3. Organization-less Foreman's will need to have them enabled and an initial one created
4. Users will need to be created in Pulp, and the anonymous_admin and anonymous_api_admin will need to have the correct remote_id to correspond to the Pulp admin user.
5. Locations would have to be turned on and if existing Locations then there will have to be a default location created or one of the existing locations converted to.

Installation/Configuration -- ehelms/sloranz¶

Certs

Katello requires a number of certificates in order to deploy all of the services that are involved. For a summary of all the certs that are used and deployed see [1]. In order for us to install the Katello plugin alongside an existing Foreman installation, we will need to support deploying certs for new services as well as, in some situations, changing the certs currently being used by Foreman.

The current design of our certs management is:

1. We use a centralized puppet-certs that contains manifests for each service
2. puppet-certs handles generating a CA that is used for each set of certs
3. puppet-certs handles user supplied server certificates
4. puppet-certs uses Puppet providers that currently only work with the katello-certs-tools library
5. katello-certs-tools is a python based command line tool that uses RPMs to wrap certs and deploy them

Issues:

1. Do we keep the singular puppet-certs for managing and orchestrating our certs or break it up so that each module is managing what it requires certs wise with parameters?
2. Do we ditch katello-certs-tools in favor of puppet-openssl [2] ? This may require pushing some changes into the library for our needs. We will still need a way to generate and deploy our bootstrap RPM.
3. Do we detangle and ditch our nssdb management in favor of puppet-nsstools [3] ? Should the nssdb management be moved into our puppet-qpid since nss is predominantly required by qpid?
4. What is the best strategy for de-coupling our puppet modules and ensuring they can be imported to manage the configuration of the server itself?
5. How do we handle the answers file from older Foreman installations?

Rake Tasks

Katello currently relies on installing and configuring itself and then letting the Foreman installation happen as normal. This is so that as rake tasks such as migrate, seed and api pie cache are run, the Katello migrations, seeds and APIs are included. Further, Katello requires services (Pulp, Candlepin, Elasticsearch) to be running in order to seed the database.

Issues:

1. Foreman rake tasks in puppet are currently designed to run once, how do we modify this behavior such that Katello can come along and run them for it's needs?
2. Katello seeds need to be updated to ensure that backend users are created properly
3. Katello seeds needs to be updated to ensure organizations get created in Candlepin

Answers file vs. Orchestration Module

Katello currently uses a single module to orchestrate all services and certs being done in the correct order [4]. The Kafo answers file also serves as a method for combining a number of services and orchestrating parameters to them. Further, only module declared within the answers file can be tuned via parameters. Thus, if a module, such as Pulp, exposed a new configuration option the orchestration module would have to also be updated to expose this. In the answers file method, this option would be exposed to the user by simply updating the Pulp module within the installer.

Issues:

1. Does a single orchestration module make the most sense or should we be taking advantage of the answers file method?

Capsules -- lzap¶

Katello deploys Capsules which includes deploying the following:

• Smart Proxy
• Pulp Node or Pulp Master
• Certs
• Qpid
• Puppet Master

Issues:

1. Existing smart proxies would require updated certs based on the Katello certs deployment.
2. Are Capsules really just Smart Proxies? or does the current paradigm of Capsules being Smart Proxies + additional services (e.g. Pulp, qpid, reverse proxy) still make sense?
3. puppet-capsule currently wraps foreman-proxy, thus to expose new foreman-proxy options we have to expose them in puppet-capsule as options
   Packaging

Documentation¶

Bugs/RFE¶

Use Cases¶

Requirements¶