Hi all,
I'm considering refactoring how prefetching and purging work,
essentially merging them into a single process. The direct motivation
is because I'm trying to make it possible to purge resources that use
ParsedFile providers (a customer is funding the work, because they
want to purge Nagios resources). Essentially, the current model makes
purging not work if you're using non-default locations for your
ParsedFile resources.
I mostly need to know if 1) my plans are just stupid for some reason,
and 2) if someone else has a resource type out there that falls
outside the model I'm using.
Here's the heart of what I'm imagining:
# Retrieve all known instances. Either requires providers or
must be overridden.
def prefetch_and_purge(catalog = nil)
# Put the default provider first, then the rest of the
suitable providers.
metatype = catalog.resource(:resources, self.name) if catalog
provider_instances.each do |provider|
if resource = catalog.resource(self.name, provider.name)
resource.provider = provider
elsif metatype and resource = metatype.process(provider)
catalog.add_resource resource
else
# We've got a resource that isn't managed in the
catalog or
# by the metatype, therefore we just ignore it.
end
end
end
Basically, one place where you get a list of all of the provider
instances, and you either match them against existing resources (which
is what we do during prefetching), you create a new resource but with
'ensure => absent' (which is basically what the Resources instance
does), or you ignore it (which is what we do for unmanaged resources
when we're not purging).
I expect this would end up as a class method on Puppet::Type, although
it really feels like a responsibility of the transaction.
There are some complexities that make this a bit more complicated than
I'd like, though. Specifically, a given resource might appear in
multiple sources (e.g., an rpm is going to be in yum, up2date, and
rpm), which is currently handled by declaring that all of them have
the same 'source'.
At the least, we need a way to make sure we've got the right provider
(i.e., allow someone to declare that a given resource is an rpm
resource rather than yum). I expect we would also end up with a
system that prefetched the base class (rpm, in this case) and then
allowed the subclasses to do some kind of post-processing when
appropriate.
The clean, simple 'provider_instances' method (currently a class
method on Puppet::Type) would need to become more complicated, I
think, and would need to have access to the catalog so it knew which
provider type a given resource will use.
As mentioned earlier, I'm mostly interested in knowing if someone has
a crazy-complex resource type or provider that makes this model
impossible. The yum support is probably the most complicated provider
we have right now, so it's the outlier that's defining the model,
ATM. If you've got one more complicated than that, please let me know.
I know it doesn't seem like critical work, given that I should be
working on 0.25, but this is being funded (i.e., helping pay my salary
so I can do all the other Puppet work I do), and, I think, will make
Nagios support more functional for many people. I'm doing some other
Nagios work as part of the same project, fwiw.
--
It is odd, but on the infrequent occasions when I have been called upon
in a formal place to play the bongo drums, the introducer never seems
to find it necessary to mention that I also do theoretical physics.
-- Richard Feynman
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
