Actually, that isn't going to work, I don't think. I need to have some method of flagging the uninstalled packages as needing reinstallation mid puppet run, or I need aptitude to not uninstall them in the first place, or I need to I need puppet to get kicked off on a second run at the end of the first. Of those I like the first or second options best. I'll do more digging, but would love to hear people's suggestions on this as well.
On Thursday, September 19, 2013 9:58:21 AM UTC-4, Sam Tresler wrote: > > Ah. That makes a lot of sense. I'd noticed the php5-mysql 'upgrade' and > assumed I was getting an erroneous message, but if puppet thinks it is > doing that there is actually no difference in the aptitude commands between > an install and an upgrade. The packages with names that match php5-common > *do* register as needing an upgrade at the beginning of the run, and are > actually caught and reinstalled mistakenly. Anything that doesn't need an > upgrade is never touched because it didn't need anything in the first > place. > > My predecessor switched to running puppet non-daemonized on a 20m cron > job. And I think this would not be an issue in a daemonized mode (perhaps) > - as puppet would see the inconsistency faster, which is why I can find > NOTHING on google about a similar problem. > > So, I think I'll proceed by having the php extensions without the same > versioning schema subscribe to the php5-common resource and (I'll have to > see what options are there) and check themselves again or kick off a second > puppet run immediately. > > Thanks a ton. I had all the pieces but couldn't quite see it. > > On Thursday, September 19, 2013 9:39:01 AM UTC-4, jcbollinger wrote: >> >> >> >> On Wednesday, September 18, 2013 3:01:49 PM UTC-5, Sam Tresler wrote: >>> >>> Hi, I've inherited a puppet setup for automating php installation and >>> extension management. We're on Debian and we've encountered a strange >>> issue that I've traced down back to puppet I think. I've stripped back the >>> configuration and made the problem reproducible, logs and config pasted >>> below. >>> >>> 1. php5-common, php5-memcache, and php5-mysql are all installed. >>> 2. php5-common and php5-mysql receive an update, say from >>> 5.3.3-7+squeeze14 to 5.3.3-7+squeeze17 >>> 3. Puppet runs and php5-common upgrade conflicts. Apt's first solution >>> removes php5-mysql and php5-memcache. >>> 4. Puppet continues run and re-installs/upgrades php5-mysql. It skips >>> php5-memcache. >>> 5. On a subsequent run php5-memcache is installed again as expected. >>> >>> This appears to only happen to packages that don't share the php5 >>> version naming schema, but that may be just a clue, not a cause. e.g. >>> php5-memcache is 3.0.4-4+squeeze1. >>> >> >> >> Yes, that's a clue, not the cause. Here's what I think is happening: >> >> Early in the run, before applying any resources, the Puppet agent >> "prefetches" the installed apt packages. This is a common behavior of >> providers for many resource types where it is more efficient than loading >> each declared resource's initial state individually. Puppet thereafter >> assumes that the data it has prefetched do not change except as the agent >> itself explicitly changes them. In particular, it will be caught quite by >> surprise if one of the resources it has prefetched is no longer present on >> the system when it comes time to apply it. >> >> If you look carefully at the log, you will see that it is not just >> php5-memcache about which the agent is confused. The log also says: >> 'php5-mysql "5.3.3-7+squeeze14" is installed', which is no longer true at >> the time that that message is emitted. It happens that the result is >> nevertheless what you want in that case, however, because the reason the >> package was removed is correlated with the availability of a later version >> of it. >> >> This explanation assumes that the latest available version of >> php5-memcache is the same one that was already installed at the start of >> the Puppet run. In that case, however, it is a mystery beyond my >> understanding why that package needed to be removed for the update to >> php5-common to proceed, and it was not automatically reinstalled, yet it >> could later be reinstalled manually. >> >> >> John >> >> -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
