Project

General

Profile

Katello on Existing Foreman » History » Revision 10

Revision 9 (Stephen Benjamin, 04/20/2015 08:07 AM) → Revision 10/11 (Stephen Benjamin, 05/18/2015 06:41 AM)

h1. Katello on Existing Foreman 

 h2. Summary 

 Goals: 
 # I am a user and I want to install Katello on my existing production Foreman. 


 
 # I am Foreman developer, and I want to add Katello to my development environment. 

 h2. Targeted Release 

 TBD 

 h2. Targeted Persona 

 [[Personas-SystemEngineer| Samuel - System Engineer]] - production Foreman 
 [[Personas-Developer| Daniel - Developer]] - development environment 

 h2. Design Requirements Initial Research 

 Based on https://groups.google.com/forum/#!searchin/foreman-dev/katello$20on/foreman-dev/rMc1rWJMmBg/gTjEDJuD_a0J 

 h3. Installer Data -- stbenjam/sloranz 

 katello-installer is a separate independent *Databases* 

 Katello currently only tests and supports Postgres.  

 Issues: 

 # Do we add MySQL support? 
   _It looks like it should be possible, we'd also need to add MySQL to our testing in Jenkins, and support in the installer.    As part of this effort, it Currently the migration fails with errors like this, so we will need modifications:_ 
   <pre> 
 Mysql2::Error: Error on rename of './katello/#sql-a3a_13' to move './katello/katello_content_view_filters_repositories' (errno: 150): ALTER TABLE `katello_content_view_filters_repositories` CHANGE `filter_id` `content_view_filter_id` int(11) DEFAULT NULL/home/stbenjam/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:245:in `query' 
   </pre> 
 # What about Candlepin? 
   _Theoretically supports MySQL_ 

 *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 a plugin of foreman-installer itself, that can added to an existing Foreman?- 
 # Existing Organizations need to be installed at a later point created in time.    katello-installer Candlepin 
 # Organization-less Foreman's will provide scenarios for katello need to have them enabled and a katello proxy (capsule).    Scenarios an initial one created 
 # Users will need to be able created in Pulp, and the anonymous_admin and anonymous_api_admin will need to both change have the default settings of foreman's answers (taxonomies on, certificates, etc), but also provide its own additional top-level modules. 

 Scenario Tracker http://projects.theforeman.org/issues/10161 


 > !plugins2.png! 

 In order correct remote_id to do this, puppet-foreman_proxy needs correspond to the Pulp admin user. 
 # Locations would have to be moved turned on and if existing Locations then there will have to the top level be a default location created or one of the installer, puppet-capsule largely stripped and renamed to indicate its new content-specific purpose (if not able to integrate into puppet-foreman_proxy itself). 


 existing locations converted to. 

 h3. Certificates 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 https://github.com/Katello/puppet-certs#certificates-overview. [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, create new CA's (i.e. candlepin), while not breaking services as well as, in some situations, changing the existing Foreman infrastructure. certs currently being used by Foreman. 

 In order 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 accomplish this, wrap certs and deploy them 

 Issues: 
 # Do we will abandon keep the current katello-certs-tool singular puppet-certs for managing and puppet-certs, 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 a puppet-openssl module.    Optionally, [2] ? This may require pushing some changes into the katello library for our needs. We will still need a way to generate and candlepin CA's can deploy our bootstrap RPM. 
 # Do we detangle and ditch our nssdb management in favor of puppet-nsstools [3] ? Should the nssdb management be issued moved into our puppet-qpid since nss is predominantly required by an existing CA (such as qpid? 
 # What is the Puppet CA), keeping best strategy for de-coupling our puppet modules and ensuring they can be imported to manage the foreman infrastructure intact and functioning. configuration of the server itself? 
 # How do we handle the answers file from older Foreman installations? 

 h3. Backends *Rake Tasks* 

 Katello has three main backends currently relies on installing and configuring itself and then letting the Foreman installation happen as normal. This is so that store data: Pulp, Candlepin as rake tasks such as migrate, seed and Elasticsearch. Some api pie cache are run, the Katello objects have corresponding objects migrations, seeds and APIs are included. Further, Katello requires services (Pulp, Candlepin, Elasticsearch) to be running in one or all backends.  

 order to seed the database. 

 Issues: 
 # Foremans will need Foreman rake tasks in puppet are currently designed to have Organizations run once, how do we modify this behavior such that Katello can come along and Locations enabled and an initial one created (done with the scenario) run them for it's needs? 
 # Existing Organizations Katello seeds need to be updated to ensure that backend users are created in Candlepin properly 
 # Users will need Katello seeds needs to be updated to ensure organizations get created in Pulp, Candlepin 

 *Answers file vs. Orchestration Module* 

 Katello currently uses a single module to orchestrate all services and certs being done in the anonymous_admin correct order [4]. The Kafo answers file also serves as a method for combining a number of services and anonymous_api_admin will need 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 the correct remote_id to correspond also be updated to expose this. In the Pulp admin user. 

 h3. Databases 

 Katello currently only tests and supports Postgres.  

 Requirements: 

 # Support MySQL 

   _It looks like it should answers file method, this option would be possible, we'd also need exposed to add MySQL to our testing in Jenkins, and support in the user by simply updating the Pulp module within the installer.    Currently 

 Issues: 
 # Does a single orchestration module make the migration fails with errors like this, so most sense or should we will need modifications:_ 

   <pre> 
 Mysql2::Error: Error on rename be taking advantage of './katello/#sql-a3a_13' to './katello/katello_content_view_filters_repositories' (errno: 150): ALTER TABLE `katello_content_view_filters_repositories` CHANGE `filter_id` `content_view_filter_id` int(11) DEFAULT NULL/home/stbenjam/.rvm/gems/ruby-1.9.3-p448/gems/activerecord-3.2.21/lib/active_record/connection_adapters/abstract_mysql_adapter.rb:245:in `query' 
   </pre> the answers file method? 

 # What about Candlepin? 
   _Theoretically supports MySQL_ 


 h3. Capsules -- lzap 

 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 upstream should really just become Foreman Smart Proxies.    This means moving Foreman Proxy module to Proxies? or does the top level, and either integrating existing Katello functions into plugins for the puppet-foreman_proxy module, or providing it externally through our own content-specific module (stripped down version current paradigm of the existing capsule module). 


 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 
 Packaging 

 h2. Documentation 

 h3. Bugs/RFE 

 * Tracker http://projects.theforeman.org/issues/7605  

 h3. Use Cases 

 h3. Requirements