On Dec 23, 2010, at 14:56, Stefan Schulte
<[email protected]> wrote:
> On Wed, Dec 22, 2010 at 09:55:27AM -0800, Luke Kanies wrote:
>> It's a bit more complicated for packages, because the dependency trees are
>> so large, but is it possible to pull the dependency graph of these services?
>>
>> IMO, that's the "right" long-term direction: importing external dependency
>> graphs so we don't have this kind of problem. Anything else is essentially
>> hacking around the actual problem. In terms of hacking around the problem,
>> the best answer that I can see is something like the clean/dirty bits. Yes,
>> you can still break it, but it's the best we can get.
>
> Just had another thought. If someone specifies
> # Assume that openssh and /etc/init.d/sshd are absent and I'd apply
> package { 'openssh': ensure => installed }
> service { 'sshd': ensure => running, require => Package['openssh']}
>
> Prefetching services would make no sense here, because the service ssh
> would just be absent. And after the package is installed it might run.
> So even resources of another type can influence my service resource.
> Arg. Seems like prefetching isnt such a brilliant idea after all...
>
> Maybe it's just useful where it is used right now: In the parsedfile
> provider.
Prefetching was mostly invented for packages, and there are similar
issues there. You basically have to make a trade-off between speed
and perfection here, and it seems to be working in most cases.
--
http://puppetlabs.com/ | +1-615-594-8199 | @puppetmasterd
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
