On Thursday, 12 March 2015 00:39:53 UTC+11, jcbollinger wrote:
>
>
>
> On Tuesday, March 10, 2015 at 10:30:48 PM UTC-5, Amos Shapira wrote:
>>
>> Hi,
>>
>> I'm running into the common issue of having to force an "apt-get update"
>> before installing packages (in my case - because the base EC2 AMI is old
>> and I need it to pick newer package versions).
>>
>> I ended up doing the usual:
>>
>> exec { 'apt-get update':
>> path => '/usr/bin/',
>> }
>> ->
>> Package <| |>
>>
>>
>
> If you are using PuppetLabs's Apt module, then I think setting the
> 'always_apt_update => true' on class 'apt' and declaring
>
> Class['Apt'] -> Package <| |>
>
>
> should take care of it for you. That module's 'apt::update' class is not
> really suited to be public, given the way the module uses it.
>
>
Thanks. I'm aware of the "always_apt_update" option but am worried that it
means that puppet will force an "apt-get update" every time it runs (every
30 minutes). We will eventually move away from puppet agents to immutable
images but until then I'm worried that this could stir up a lot of load on
our EC2 instances which we wouldn't want.
Perhaps I should reconsider this option.
>
>
>> (I can't use "apt::update" because it creates dependency cycles) and it
>> works.
>>
>> But what baffles me is that I really only need "apt-get update" to
>> execute before "apt" packages get installed, like this:
>>
>> Package <| provider = "apt" |>
>>
>> But this doesn't trigger the "apt-get update".
>>
>> Just as an example, I also have a Gem-provider related exec which works
>> as expected:
>>
>> exec { 'Add Ruby Gems repo mirror':
>> command => 'gem source --config-file /etc/gemrc -a
>> http://production.cf.rubygems.org/',
>> unless => 'gem source --config-file /etc/gemrc | fgrep -xq
>> http://production.cf.rubygems.org/',
>> path => '/usr/bin:/bin',
>> }
>> ->
>> Package<| provider == 'gem' |>
>>
>> So why doesn't it work for the "apt" provider?
>>
>>
>
> Resource collectors operate during catalog building. Their selection
> predicates can see only parameter and property values *explicitly*
> declared in your manifests. It does not know what values will be effective
> at catalog application time for any other parameters. In particular, it
> does not know what provider will be selected during catalog application
> unless one is specified in the manifest, which is not usual when the
> system's default provider is expected.
>
> To the best of my knowledge, the "gem" provider is not the default for any
> system, so you get it only when you specifically ask for it. That's why
> you can reliably select gem Packages by provider. 'Apt' is normally the
> default Package provider on systems that support it at all. Your selection
> predicate will not match Package resources that rely 'apt' being selected
> by default.
>
Thanks for the explanation. That makes sense. Mystery answered :)
>
>
> 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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/5b4569a1-b6c5-4d48-8942-70f26e1523ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
