Sam Tresler
2013-Sep-18 20:01 UTC
[Puppet Users] Puppet requires second run to execute some catalog items.
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.
I have:
package { "php5-common": ensure => latest }
php_module { "mysql":
ensure => $php5_mysql ? {
''1'' => ''enable'',
''0'' => ''absent'',
},
}
php_module { "memcache":
ensure => $php5_memcache ? {
''1'' => ''enable'',
''0'' => ''absent'',
},
}
define php_module ( $ensure = ''enable'' ) {
if $ensure == "enable" {
package {
"php5-${name}": ensure => latest,
require => [ Package[ ''php5-common''], Package[
''php5-cgi'' ],
Package[ ''php5'' ], Package[
''libapache2-mod-php5'' ] ],
}
} else {
package { "php5-${name}": ensure => absent }
}
}
In the debug of a run, I see (relevant lines only):
231 ^[[0;36mDebug:
/Stage[main]/Php/Php::Php_module[memcache]/Package[php5-memcache]/require:
requires Package[php5-common]^[[0m
232 ^[[0;36mDebug:
/Stage[main]/Php/Php::Php_module[memcache]/Package[php5-memcache]/require:
requires Package[php5-cgi]^[[0m
233 ^[[0;36mDebug:
/Stage[main]/Php/Php::Php_module[memcache]/Package[php5-memcache]/require:
requires Package[php5]^[[0m
234 ^[[0;36mDebug:
/Stage[main]/Php/Php::Php_module[memcache]/Package[php5-memcache]/require:
requires Package[libapache2-mod-php5]^[[ 0m
327 ^[[0;36mDebug:
/Stage[main]/Php/Php::Php_module[mysql]/Package[php5-mysql]/require:
requires Package[php5-common]^[[0m
328 ^[[0;36mDebug:
/Stage[main]/Php/Php::Php_module[mysql]/Package[php5-mysql]/require:
requires Package[php5-cgi]^[[0m
329 ^[[0;36mDebug:
/Stage[main]/Php/Php::Php_module[mysql]/Package[php5-mysql]/require:
requires Package[php5]^[[0m
330 ^[[0;36mDebug:
/Stage[main]/Php/Php::Php_module[mysql]/Package[php5-mysql]/require:
requires Package[libapache2-mod-php5]^[[0m
487 ^[[0;36mDebug: Executing ''/usr/bin/apt-cache policy
php5-common''^[[0m
488 ^[[0;36mDebug: /Stage[main]/Php/Package[php5-common]/ensure:
php5-common "5.3.3-7+squeeze14" is installed, latest is
"5.3.3-7+sque
eze17"^[[0m
489 ^[[0;36mDebug: Executing ''/usr/bin/aptitude -y -o
DPkg::Options::=--force-confold install php5-common''^[[0m
490 ^[[mNotice: /Stage[main]/Php/Package[php5-common]/ensure: ensure
changed ''5.3.3-7+squeeze14'' to
''5.3.3-7+squeeze17''^[[0m
491 ^[[0;36mDebug: /Stage[main]/Php/Package[php5-common]: The container
Class[Php] will propagate my refresh event^[[0m
547 ^[[0;36mDebug: Executing ''/usr/bin/apt-cache policy
php5-memcache''^[[0m
615 ^[[0;36mDebug: Executing ''/usr/bin/apt-cache policy
php5-mysql''^[[0m
616 ^[[0;36mDebug:
/Stage[main]/Php/Php::Php_module[mysql]/Package[php5-mysql]/ensure:
php5-mysql "5.3.3-7+squeeze14" is installed, la test is
"5.3.3-7+squeeze17"^[[0m
617 ^[[0;36mDebug: Executing ''/usr/bin/aptitude -y -o
DPkg::Options::=--force-confold install php5-mysql''^[[0m
618 ^[[mNotice:
/Stage[main]/Php/Php::Php_module[mysql]/Package[php5-mysql]/ensure: ensure
changed ''5.3.3-7+squeeze14'' to ''5.3.3-7+squ
eeze17''^[[0m
619 ^[[0;36mDebug:
/Stage[main]/Php/Php::Php_module[mysql]/Package[php5-mysql]: The container
Php::Php_module[mysql] will propagate my refresh event^[[0m
620 ^[[0;36mDebug: Php::Php_module[mysql]: The container Class[Php] will
propagate my refresh event^[[0m
So, why, on line 547, when memcache is definitely not installed does it not
install it? I''ve been on this for 3 days and am officially stumped. Any
help would be appreciated.
--
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+unsubscribe@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.
jcbollinger
2013-Sep-19 13:39 UTC
[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+unsubscribe@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.
Sam Tresler
2013-Sep-19 13:58 UTC
[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+unsubscribe@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.
Sam Tresler
2013-Sep-19 15:23 UTC
[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+unsubscribe@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.
Chris McDermott
2013-Sep-25 03:58 UTC
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 <samtresler@gmail.com> 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 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+unsubscribe@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. >-- 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+unsubscribe@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.
Sam Tresler
2013-Sep-25 13:14 UTC
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+unsubscribe@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.
Sam Tresler
2013-Sep-25 13:17 UTC
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
<samtr...@gmail.com<javascript:>
> > 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 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...@googlegroups.com <javascript:>.
>> To post to this group, send email to
puppet...@googlegroups.com<javascript:>
>> .
>> Visit this group at http://groups.google.com/group/puppet-users.
>> For more options, visit https://groups.google.com/groups/opt_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+unsubscribe@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.
jcbollinger
2013-Sep-25 15:51 UTC
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+unsubscribe@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.