Project

General

Profile

User story #8230

Updated by Alexis Mousset over 7 years ago

h2. Status of package management 

 This table only considers latest versions of techniques and generic methods. 

 |_.name|_.OS|_.body|_.package list update frequency (yum update, etc.)|_.package list update frequency configurable?|_.handles installing "latest" version|_.available updates list frequency configurable?|_.handles "update or add if not installed"|_.handles "install a specific, not latest version"|_.execution installed"|_.execution frequency configurable (class persistence)| 
 |rpm package installation 7.0 technique|RHEL/CentOS/SLES|generic_nobulk (in the technique)| 30 minutes | no | yes | yes (default is 60 minutes) | no | no | yes (default to 60 minutes)| 
 |apt package installation 4.0 technique|Ubuntu/Debian|apt_nobulk (in the technique)|30 minutes | no | no | no | no| no | no| 
 |package_install_* generic methods|Debian/Ubuntu|apt_get (in cfengine stdlib)|240 minutes| no | no | no | yes | no| no | 
 |package_install_* generic methods|RHEL/CentOS|yum_rpm (in cfengine stdlib)|240 minutes| no | no | no | yes |no| | no | 
 |package_install_* generic methods|SLES|ncf_generic (in ncf stdlib)|240 minutes | no | no | no | yes|yes yes | no | 
 |package_{present,absent} generic methods|RHEL,Debian/Ubuntu,FreeBSD|    | 240 minutes ? | no ? | yes | no ? | yes |yes| | no | 

 Constraints: 
 * The addupdate action does not work 
 * We need to handle "update to latest version" manually using a list of available updates to call CFEngine with a precise version 
 * ncf does not (currently) handles reporting for multiple calls with the same generic method on the same package 
 * We have to stay compatible with all current package management methods 

 Goals: 
 * Ability to ensure the package is in "latest" version 
 * Ability to update or install if needed in a single action 
 * Flexibility on caching/execution frequency to allow: 
 ** Fast actions (provisioning, security updates, ...) 
 ** Low overhead on small/embedded devices 
 * Fix targeting current versions, at least 3.1 

 h2. Option 1 

 Make one configurable package management method working properly and use it everywhere. 

 * Use @ncf_generic@ body everywhere in ncf 
 * Add available updates list support to package_install_* 
 ** Move rpm support to the generic method 
 ** Add apt support 
 * Make list update frequency configurable 
 ** ncf configuration parameter ? 
 ** Generic method parameter ? 
 * Make a new version of RPM and APT package techniques using @package_install_@ 

 Issues: 
 * Some people implemented addupdate using directives with add+update on the same package, which cannot be handled properly with ncf reporting 

 h2. Option 2 

 Make one configurable package management method working properly in ncf, and fix packages techniques by handling add + update actions 

 * Use @ncf_generic@ body everywhere in ncf 
 * Add available updates list support to package_install_* 
 * Add support for available updates in apt technique 
 * Make list update frequency configurable in ncf (and maybe in the techniques too) 
 ** ncf configuration parameter ? 
 ** Generic method parameter ? 

 Issues: 
 * Duplicates a lot of logic in ncf/techniques 

 h2. Other notes 

 We should have a plan to migrate to the new CFEngine package promises, which are now the default in 3.9. This should widely simplify our code on new CFEngine version (Rudder 3.2+). We can use if_version macro feature for this, which will be easier if all package operations are done in a single place.

Back