User story #8230
Updated by Alexis Mousset over 8 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"|_.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 | 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|
|package_install_* generic methods|Debian/Ubuntu|apt_get (in cfengine stdlib)|240 minutes| no | no | no | yes | no |
|package_install_* generic methods|RHEL/CentOS|yum_rpm (in cfengine stdlib)|240 minutes| no | no | no | yes | no |
|package_install_* generic methods|SLES|ncf_generic (in ncf stdlib)|240 minutes | no | no | no | 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.