Re: [Puppet Users] Re: Puppet requires second run to execute some catalog items.
On Wednesday, September 25, 2013 8:17:42 AM UTC-5, Sam Tresler wrote: > > Precisely. Aptitude is the culprit here. I've switched our package manager > to apt which is more conservative and it does not remove the packages when > upgrading php, which, for now is a workable solution. I need to find the > time to put this in as Debian bug and see what they say. > > I can't see a plausible explanation for why requesting an upgrade to one > package could feasibly result in the removal of the same package (same > thing happens if you upgrade an extension first). > > e.g. > > root@vpstest# aptitude install php5-mysql > The following packages will be upgraded: > php5-common php5-mysql > 2 packages upgraded, 0 newly installed, 0 to remove and 29 not upgraded. > Need to get 0 B/633 kB of archives. After unpacking 0 B will be used. > The following packages have unmet dependencies: > php5-xsl: Depends: php5-common (= 5.3.3-7+squeeze14) but > 5.3.3-7+squeeze17 is to be installed. > libapache2-mod-php5: Depends: php5-common (= 5.3.3-7+squeeze14) but > 5.3.3-7+squeeze17 is to be installed. > php5-mcrypt: Depends: php5-common (= 5.3.3-7+squeeze14) but > 5.3.3-7+squeeze17 is to be installed. > php5-cgi: Depends: php5-common (= 5.3.3-7+squeeze14) but > 5.3.3-7+squeeze17 is to be installed. > php5-cli: Depends: php5-common (= 5.3.3-7+squeeze14) but > 5.3.3-7+squeeze17 is to be installed. > The following actions will resolve these dependencies: > > Remove the following packages: > 1) libapache2-mod-php5 > 2) php-apc > 3) php-pear > 4) php5 > 5) php5-adodb > 6) php5-cgi > 7) php5-cli > 8) php5-imagick > 9) php5-mcrypt > 10) php5-memcache > 11) php5-memcached > 12) php5-mysql > 13) php5-suhosin > 14) php5-xsl > > > #12 on that list is the package I am requesting be upgraded/installed. How > can its removal ever be an intended result? > In fairness, removal of a package whose update was requested is not the problem (or at least not much of one), because it is implicit that the newer version will thereafter be installed in the same run. The problem is all the other packages that get removed instead of being updated. 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 puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Puppet requires second run to execute some catalog items.
Precisely. Aptitude is the culprit here. I've switched our package manager to apt which is more conservative and it does not remove the packages when upgrading php, which, for now is a workable solution. I need to find the time to put this in as Debian bug and see what they say. I can't see a plausible explanation for why requesting an upgrade to one package could feasibly result in the removal of the same package (same thing happens if you upgrade an extension first). e.g. root@vpstest# aptitude install php5-mysql The following packages will be upgraded: php5-common php5-mysql 2 packages upgraded, 0 newly installed, 0 to remove and 29 not upgraded. Need to get 0 B/633 kB of archives. After unpacking 0 B will be used. The following packages have unmet dependencies: php5-xsl: Depends: php5-common (= 5.3.3-7+squeeze14) but 5.3.3-7+squeeze17 is to be installed. libapache2-mod-php5: Depends: php5-common (= 5.3.3-7+squeeze14) but 5.3.3-7+squeeze17 is to be installed. php5-mcrypt: Depends: php5-common (= 5.3.3-7+squeeze14) but 5.3.3-7+squeeze17 is to be installed. php5-cgi: Depends: php5-common (= 5.3.3-7+squeeze14) but 5.3.3-7+squeeze17 is to be installed. php5-cli: Depends: php5-common (= 5.3.3-7+squeeze14) but 5.3.3-7+squeeze17 is to be installed. The following actions will resolve these dependencies: Remove the following packages: 1) libapache2-mod-php5 2) php-apc 3) php-pear 4) php5 5) php5-adodb 6) php5-cgi 7) php5-cli 8) php5-imagick 9) php5-mcrypt 10) php5-memcache 11) php5-memcached 12) php5-mysql 13) php5-suhosin 14) php5-xsl #12 on that list is the package I am requesting be upgraded/installed. How can its removal ever be an intended result? On Tuesday, September 24, 2013 11:58:27 PM UTC-4, mcd wrote: > > I guess I'm confused at why aptitude would remove php5-memcache in order > to upgrade php5-common. Or if it really needed to do that, shouldn't it be > smart enough to automatically install the upgraded version? I confess I'm > more familiar with RedHat/CentOS, and Yum is smart enough to handle > upgrading packages and their dependencies smoothly. I had though aptitude > was smart enough too, based on my limited experience with it. Anyway, if > you're still stuck I guess that's what I would try to figure out. > > > On Thu, Sep 19, 2013 at 9:23 AM, Sam Tresler > > wrote: > >> 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
Re: [Puppet Users] Re: Puppet requires second run to execute some catalog items.
Precisely. Aptitude is the culprit here. I've switched our package manager to apt which is more conservative and it does not remove the packages when upgrading php, which, for now is a workable solution. I need to find the time to put this in as Debian bug and see what they say. I can't see a plausible explanation for why requesting an upgrade to one package could feasibly result in the removal of the same package (same thing happens if you upgrade an extension first). e.g. root@vps814:/home/cadre/stresler# aptitude install php5-mysql The following packages will be upgraded: php5-common php5-mysql 2 packages upgraded, 0 newly installed, 0 to remove and 29 not upgraded. Need to get 0 B/633 kB of archives. After unpacking 0 B will be used. The following packages have unmet dependencies: php5-xsl: Depends: php5-common (= 5.3.3-7+squeeze14) but 5.3.3-7+squeeze17 is to be installed. libapache2-mod-php5: Depends: php5-common (= 5.3.3-7+squeeze14) but 5.3.3-7+squeeze17 is to be installed. php5-mcrypt: Depends: php5-common (= 5.3.3-7+squeeze14) but 5.3.3-7+squeeze17 is to be installed. php5-cgi: Depends: php5-common (= 5.3.3-7+squeeze14) but 5.3.3-7+squeeze17 is to be installed. php5-cli: Depends: php5-common (= 5.3.3-7+squeeze14) but 5.3.3-7+squeeze17 is to be installed. The following actions will resolve these dependencies: Remove the following packages: 1) libapache2-mod-php5 2) php-apc 3) php-pear 4) php5 5) php5-adodb 6) php5-cgi 7) php5-cli 8) php5-imagick 9) php5-mcrypt 10) php5-memcache 11) php5-memcached 12) php5-mysql 13) php5-suhosin 14) php5-xsl #12 on that list is the package I am requesting be upgraded/installed. How can its removal ever be an intended result? On Tuesday, September 24, 2013 11:58:27 PM UTC-4, mcd wrote: > I guess I'm confused at why aptitude would remove php5-memcache in order > to upgrade php5-common. Or if it really needed to do that, shouldn't it be > smart enough to automatically install the upgraded version? I confess I'm > more familiar with RedHat/CentOS, and Yum is smart enough to handle > upgrading packages and their dependencies smoothly. I had though aptitude > was smart enough too, based on my limited experience with it. Anyway, if > you're still stuck I guess that's what I would try to figure out. > > -- 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 puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Puppet requires second run to execute some catalog items.
I guess I'm confused at why aptitude would remove php5-memcache in order to upgrade php5-common. Or if it really needed to do that, shouldn't it be smart enough to automatically install the upgraded version? I confess I'm more familiar with RedHat/CentOS, and Yum is smart enough to handle upgrading packages and their dependencies smoothly. I had though aptitude was smart enough too, based on my limited experience with it. Anyway, if you're still stuck I guess that's what I would try to figure out. On Thu, Sep 19, 2013 at 9:23 AM, Sam Tresler wrote: > 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
[Puppet Users] Re: Puppet requires second run to execute some catalog items.
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 puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Puppet requires second run to execute some catalog items.
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 puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Puppet requires second run to execute some catalog items.
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 puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
