Andrew Shafer schrieb: > You created the type which provides an interface for something that you wish > to model.
Yes, that much I understood. > The 'ensurable' call is going to do something very similar to the ensure > definition you defined with a block, but they can't both exists. This is also mostly understood. However: if I use "ensurable", can I extend it to support addional "ensure" states? If not, how do I implement the ensure interface? > ensureable is going to look for an exists? method on the 'provider', and it > doesn't look like you have one. Well, that much I know, but I don't really understand the relationship between a type and a provider. I know there are often several providers for a type (package type has at least dpkg, yum, gem, apt, though there is only one for parsedfile - as it is the basis for others), I also understand the "defaultfor:" part. But what a provider really needs in my case is beyond me. In other words: I would really appreciate something like the PracticalTypes page which goes on to describe "ensurable" and how to write a provider for it. > The idea is that types model something at a high level and providers give > you portability across platforms. (in this case, you are trying to support > something very specific to certain platforms) Well, yes, but I wanted to implement something like an "installserver" type collection, which can use cobbler as the backend in an RHEL environment while using some other backend in other environments. In the end, even a relatively generic backend directly configuring tftp, dhcp, dns, repositories (of different types) and webserver would be possible. So a generic type would be nice, I just started out with the described relatively simple interface to learn how this has to be done. And I didn't want to polute the namespace I intended for the later interface. regards, Sven > On Fri, Sep 26, 2008 at 4:07 AM, Sven Mueller <[EMAIL PROTECTED]>wrote: > >> Sven Mueller schrieb: >>> I did write a preliminary type, but it doesn't seem to work at all (see >>> below). I put the attached file in >>> /etc/puppet/modules/puppet/type/cobbler_repo.rb as per >>> http://reductivelabs.com/trac/puppet/wiki/PluginsInModules, with >>> effective puppetmasterd configuration containing: >>> modulepath = /etc/puppet/modules:/usr/share/puppet/modules >>> >>> But still I get: >>> >>> err: Could not retrieve catalog: Could not find resource type >>> cobbler_repo at /etc/puppet/manifests/classes/cobbler.pp:171 on node >>> op-inst01.wirecard.sys >> Forget about that. I forgot to enable pluginsync. >> >> Anyway, I now get: >> >> warning: Configuration could not be instantiated: Class cobbler_repo >> already has a property named ensure >> >> If I remove the newproperty(:ensure) block, I get: >> >> err: //Node[op-inst01.wirecard.sys]/cobbler/Cobbler_repo[CentOS5]: >> Failed to retrieve current state of resource: No ability to determine if >> cobbler_repo exists >> >> instead. Now, how do I add that ability (plus the "insync" meaning of >> :ensure)? >> >> kind regards, >> Sven >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
