Project

General

Profile

Katello on Existing Foreman » History » Version 2

Stephen Benjamin, 03/30/2015 07:03 AM

1 1 Stephen Benjamin
h1. Katello on Existing Foreman
2
3
h2. Summary
4
5
Goals:
6
# I am a user and I want to install Katello on my existing production Foreman.
7
# I am Foreman developer, and I want to add Katello to my development environment.
8
9
h2. Targeted Release
10
11 2 Stephen Benjamin
TBD
12 1 Stephen Benjamin
13
h2. Targeted Persona
14
15
[[Personas-SystemEngineer| Samuel - System Engineer]] - production Foreman
16
[[Personas-Developer| Daniel - Developer]] - development environment
17
18 2 Stephen Benjamin
h2. Initial Research
19
20
Based on https://groups.google.com/forum/#!searchin/foreman-dev/katello$20on/foreman-dev/rMc1rWJMmBg/gTjEDJuD_a0J
21 1 Stephen Benjamin
22
h3. Data -- bbuckingham/sloranz
23
24
*Databases*
25
26
Katello currently only tests and supports Postgres. 
27
28
Issues:
29
30
# Do we add MySQL support?
31
32
*Backends*
33
34
Katello has three main backends that store data: Pulp, Candlepin and Elasticsearch. Some Katello objects has corresponding objects in one or all backends. 
35
36
Issues:
37
38
# 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?
39
# Existing Organizations need to be created in Candlepin
40
# Organization-less Foreman's will need to have them enabled and an initial one created
41
# 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.
42
# 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.
43
44
h3. Installation/Configuration -- ehelms/sloranz
45
46
*Certs*
47
48
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.
49
50
The current design of our certs management is:
51
# We use a centralized puppet-certs that contains manifests for each service
52
# puppet-certs handles generating a CA that is used for each set of certs
53
# puppet-certs handles user supplied server certificates
54
# puppet-certs uses Puppet providers that currently only work with the katello-certs-tools library
55
# katello-certs-tools is a python based command line tool that uses RPMs to wrap certs and deploy them
56
57
Issues:
58
# 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?
59
# 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.
60
# 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?
61
# 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?
62
# How do we handle the answers file from older Foreman installations?
63
64
*Rake Tasks*
65
66
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.
67
68
Issues:
69
# 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?
70
# Katello seeds need to be updated to ensure that backend users are created properly
71
# Katello seeds needs to be updated to ensure organizations get created in Candlepin
72
73
*Answers file vs. Orchestration Module*
74
75
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.
76
77
Issues:
78
# Does a single orchestration module make the most sense or should we be taking advantage of the answers file method?
79
80
h3. Capsules -- lzap
81
82
Katello deploys Capsules which includes deploying the following:
83
84
* Smart Proxy
85
* Pulp Node or Pulp Master
86
* Certs
87
* Qpid
88
* Puppet Master
89
90
Issues:
91
# Existing smart proxies would require updated certs based on the Katello certs deployment.
92
# 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?
93
# puppet-capsule currently wraps foreman-proxy, thus to expose new foreman-proxy options we have to expose them in puppet-capsule as options
94
Packaging
95
96
h2. Documentation
97
98
h3. Bugs/RFE
99
100
h3. Use Cases
101
102
h3. Requirements