And oh, yes. No cookbook that I can see in the supermarket currently does a general “yum update”. The “yum_package” tool certainly accepts the option to do updates, but many cookbooks don’t provide settings to activate that. And since a typical scheduled chef run with an embedded “yum update” might cause kernel confusion, might restart services, and since various chef cookbooks would need to be re-run to restore settings after a “yum update” operation repopulates config files deleted by the previous chef tun, it’s not really a safe operation to do by default with chef. A separate, scheduled operation to do a run of an internally generated recipe running the command “yum -y update”, triggered during maintenance windows and followed by a standard chef run, can work and I’ve used that approach. It’s a great scheduled operation for maintenance windows. But you should absolutely do it on a test host or test environments first, to ensure that upstream changes don’t break your chef managed configs. (SELinux, I’m looking at you!)
Most chef recipes are supposed to be idempotent. A chef run that includes a “yum update” can break the idempotence of various recipes due to various configurations by restoring default config files that are incompatible with the current chef cookbook managed configuration. Examples especially include all mysql based RPMs that populate /etc/my.cnf, tomcat by installing a tomcat on the default network ports that may conflict with the instances crated by the cookbok, httpd for repopulating /etc/httpd files, and nginx fore re-installing the nginx default files. It’s just not a safe operation on an active server unless you’re prepared for a service interruption and prepared to re-run chef and clean up the potential mess left by new upstream RPMs with new config files.