Story #3716

Updated by bmbouter almost 6 years ago

h3. Motivation 

 1. "Installation of Pulp": is complicated and could be made much easier with an Ansible installer. 

 2. Clustered based installs are also very complicated. Typically users want to install some mixture of Pulp services on different hosts. Doing this consistently is time consuming and error prone. Ansible could install in clusered environments very well. 

 h3. Usage 

 The installer will live as a collection of roles published via the 'pulp' user on Ansible Galaxy. That will cause it to be available "here":    Each role will install a pulp component, and using an Ansible playbook the user can select which roles will run on any given host or host group. Here are the roles we foresee: 

 * pulp3 - install the pulp virtualenv and any plugins 
 * webserver - depends on pulp3. Installs the webserver of choice. Install systemd unit file for webserver. Set to autostart. 
 * resource manager - depends on pulp3. Installs resource manager systemd unit file. Set to autostart 
 * workers - depends on pulp3. Installs workers systemd unit files. Set to autostart 
 * Redis - hopefully an existing Role on Galaxy named in our playbooks as a dependency 
 * Postgres - hopefully an existing Role on Galaxy named in our playbooks as a dependency 

 h3. Features 

 * Generic plugin installation as specified by Ansible variables. Any plugin that only requires a pip install command and the migrations run will work 
 * Install and configure Redis on a specific host in the inventory. 
 * Install and configure Postgres on a specific host in the inventory. 
 * Installs the virtualenv to be used in a role. 
 * Can optionally install to the system packages without a virtualenv 
 * Installs systemd units for a webserver, workers, or resource manager on one or more host in the inventory 
 * Allows a choice of Nginx or Apache (defaults to nginx) 
 * Allows for custom file provided by the user 
 * Provides sparse by default 
 * Idempotent 

 h3. Assumptions 

 h5. Dependency 

 This assumes that the installing the plugin will bring all of it's necessary dependencies including pulpcore.plugin and pulpcore itself. Specifically plugins are recommended to depend on pulpcore.plugin. That would bring in dependencies as follows: 

 Using Ansible variables, the Ansible installer will pip install <code>pulp_ansible</code> for example which will cause the installation of these packages:       pulp_ansible ---> pulpcore.plugin ----> pulpcore ----> pulpcore.common 

 h5. Storage 

 In multi-host environments Pulp has a shared storage requirement. The Ansible playbook does not automatically set these up. It assumes that shared storage is already setup correctly. 

 h5. Root Access 

 At a few points in the playbook, root is required so it's assumed that the user the playbook will access has root access. Specifically root is required for the following: 

 * To install Redis, Postgres, and the webserver, you'll need root 
 * By default, the virtualenv will be created at <code>/usr/local/pulpenv</code> <code>/usr/local/</code> which typically requires root to write into 
 * In the case that virtualenv is unset, it will install Python code to the system packages which also will require root 
 * To create a user to run Pulp as will require root