On Aug 25, 2008, at 3:30 AM, Brice Figureau wrote:
>
> I have quite hard time understanding how the provider class is
> built :-(
I'll do what I can to help.
>> You'd access resource attributes like: status = resource[:hasstatus].
>
> The currently defined services seems to use @resource[:hasstatus].
> Is your code snippet a typo error or is it the real syntax?
Providers have a 'resource' attribute, so using 'resource' (without
the '@') is equivalent.
I just makes it easier to test. For instance, if you use '@resource',
then you have to do this in your test:
provider.resource = mock 'resource'
...use provider...
If you're using the attribute, you can just mock it:
provider.expects(:resource).returns mock('resource')
Same amount of code in this case, but you can actually test whether
the resource is used and how many times, which you can't as easily do
when assigning.
Really, it's kinda six of one 2pi of the other, but as a general rule
I've switched to using attributes rather than instance variables
whenever possible (and yes, I know the attributes just point to
instance variables -- it's a question of what your code directly uses,
rather than how it works internally).
>
>> Note that versions prior to, I think, 0.24.4 required you to use
>> 'resource.should(:property)' for properties. and 'resource[:param]'
>> for parameters, for backward compatbility. This has been fixed now,
>> thankfully, and the [] syntax works everywhere.
>
> OK, good to know.
>
> I have some other questions related to this provider:
>
> * I know from the provider documentation that the "commands" keyword
> check a command is present and change the suitability accordingly. I
> know about optional_command. As asked by Adam in another e-mail, if
> the
> provider supports runit, it should use another subset of commands.
> The question is how I can check the presence of the executable and
> choose a command subset instead than another?
Look at the synaptic provider -- you're going to want to create a
second 'runit' provider that just swaps out the commands.
>
> * A question related to the previous one. I want to be able to detect
> the service directory (which is usually /service or /etc/service on
> debian lenny, or /var/lib/svscan on old debian fhs). What would be the
> best way to do that?
> Should it be a new fact, or can I place FileTest heuristic directly in
> the provider class (my fear is that the class is loaded in the
> puppetmaster, hence the heuristic could be wrong)?
The class is only actually loaded on the client, and the heuristic is
definitely the right one.
Just note that you will probably want to detect it as late as possible
-- that is, don't detect it when reading the provider in, instead test
it when the provider is first used.
Something like:
# Find the service directory
def self.servicedir
unless defined?(@servicedir) and @servicedir
if FileTest.exist?("/service")...end
raise "Could not find service directory" unless @servicedir
end
end
Then use that method to access the service dir.
This way if you've got a transaction that both creates the service dir
and uses it (i.e., a package creates the dir and a service entry uses
it) then you'll be able to do it all in one go.
--
Trying to determine what is going on in the world by reading
newspapers is like trying to tell the time by watching the second
hand of a clock. --Ben Hecht
---------------------------------------------------------------------
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
-~----------~----~----~----~------~----~------~--~---
