On Thursday, March 21, 2013 6:16:07 PM UTC-5, Sam Morrison wrote:
>
> Hi,
>
> I've been battling with trying to get our puppet to do the following:
>
> Install all sources.list, apt-keys
> then:
> Run an apt-get update
> then:
> install Packages
>
> I've tried a few ways.
>
> 1. Set a default requires
>
> Package {
> require => Exec['apt_update']
> }
>
> This doesn't work, I think because some packages have a requires attribute
> and so this gets overridden.
>
That is indeed a gotcha with using resource defaults, but its not usually a
(necessary) problem for packages. You could consider looking at which
packages are declaring their own 'require's, and why. They probably don't
need to do, except as a means to achieve more or less the same thing you're
after.
In a pinch, you can always wrap package declarations in definitions so that
the defined type carries the explicit 'require' and the package just
inherits the default require, but really, I'm having trouble seeing why it
would be necessary.
>
> 2. Stages
>
> I get into huge dependency cycles doing this because I have classes that
> need apt sources that pull in other classes too, eg nagios.
>
I'm not big on stages, in large part because they significantly magnify the
risk of cycles, but more fundamentally because they inherently place many
more constraints on resource application order than are needed. There is
nothing you can do with stages that you cannot also do with ordinary
resource relationships, though using ordinary relationships may be a lot
more work for the manifest author.
>
> 3. Collectors
>
> Exec['apt_update'] -> Package <| |>
>
> This works the best but (and it's a huge but) it installs all our virtual
> packages everywhere.
>
> What would be great would be if I could do:
>
> Exec['apt_update'] -> Package
>
> But this isn't valid.
>
>
If there were a suitable a selection predicate you could use in your
collector then that might help you out. For example:
Exec['apt_update'] -> Package <| tag == 'classes_I_care_about' |>
>
> Does anyone have a sure fire way to get this to work in a large
> environment?
>
> We're using the puppetlabs apt class by the way and many other 3rd party
> modules.
>
>
I guess you're saying that you want to make everything work without
modifying any third-party modules. That might not be possible, especially
if (as I suppose) it is a requirement that the solution be flexible and
robust. Your experience with run stages may, in fact, be telling you that
there is *no* resource-application order consistent with all your
declarations that applies all apt sources and keys before all packages.
One simple way that could be true would be if any apt sources or keys were
themselves installed via packages.
I actually like the resource defaults approach, but you need to audit your
manifests, including third-party modules, to ensure that Package
declarations do not provide their own 'require's. You can allow Packages
to do so only to the extent that they are supplying their own means to your
end, including if they need to override your general rule. That's the only
reason they should need to 'require' anyway.
For the longer term, you could consider filing a feature request that would
help you out. For example, a collector selection criterion or alternative
collector syntax that collects concrete resources but does not realize
virtual ones. Actually, I think there may already be at least one ticket
that bears on that (separating resource collection from realization).
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
