A few weeks back, Katello developers discussed what would be needed in
order to allow the Katello plugin to be added to an existing Foreman.
During these discussions, some ideas were floated while others were marked
as needing further design and investigation. The following is what I have
gleaned from initial investigations. Input would be much appreciated to
fold feedback into a complete document for achieving this functionality.
In my opinion, there are 2 strategies that can be taken:
- Bend the current implementation to our will to 'make it work'
- Identify incremental changes that can be made to facilitate a proper
solution
There are 3 major areas: data, installation/configuration and capsules. If
those that are well versed in this areas find errors, please illuminate
them so that I may correct them in a final breakdown.
Initial Investigation Tests
Using our katello-deploy tooling I ran two test scenarios to test and
identify the challenges with adding a Katello plugin to an existing
Foreman. Those scenarios were:
Test 1
- Spin up CentOS 7 box
- run foreman-installer with default answers
- run katello-installer on the same box with default katello answers
Test 2
- Spin up CentOS 7 box
- run foreman-installer with default answers
- re-run foreman-installer enabling certs and certs-apache modules prior
to the foreman module in the answers, specifying the certs generated from
certs-apache as the SSL certs to foreman
Data
Databases
Katello currently only tests and supports Postgres.
Issues:
- 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:
- 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? - Existing Organizations need to be created in Candlepin
- Organization-less Foreman's will need to have them enabled and an
initial one created - 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. - 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
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:
- We use a centralized puppet-certs that contains manifests for each
service - puppet-certs handles generating a CA that is used for each set of certs
- puppet-certs handles user supplied server certificates
- puppet-certs uses Puppet providers that currently only work with the
katello-certs-tools library - katello-certs-tools is a python based command line tool that uses RPMs
to wrap certs and deploy them
Issues:
- 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? - 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. - 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? - 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?
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:
- 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? - Katello seeds need to be updated to ensure that backend users are
created properly - 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:
- Does a single orchestration module make the most sense or should we be
taking advantage of the answers file method?
Capsules
Katello deploys Capsules which includes deploying the following:
- Smart Proxy
- Pulp Node or Pulp Master
- Certs
- Qpid
- Puppet Master
Issues:
- Existing smart proxies would require updated certs based on the Katello
certs deployment. - 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? - puppet-capsule currently wraps foreman-proxy, thus to expose new
foreman-proxy options we have to expose them in puppet-capsule as options
Eric
[1] https://github.com/Katello/puppet-certs#certificates-overview
[2] https://github.com/camptocamp/puppet-openssl
[3] https://github.com/jhoblitt/puppet-nsstools
[4]
https://github.com/Katello/puppet-katello/blob/master/manifests/init.pp#L57