Nigel Kersten wrote:
So facter plugins are kind of different, as they're not actually
required to be in the puppetmaster libdir.
Say this was a type/provider, and you wanted to add a new parameter,
but only roll it out to your testing environments.
Functions also have this limitation, by the way.
What do you do then?
If the version in the puppetmaster libdir doesn't accept that
parameter, the manifest compilation will fail for clients who *are*
getting a version of the plugin that supports that parameter.
You lose...
Well, there are a couple of things you can do to work around this
limitation. For one thing, you could run a second puppetmaster
process, perhaps on another port, or listening on another IP address,
or perhaps even on another machine.
Another thing you can do, is to run puppet with local manifests,
instead of puppetd connecting to puppetmasterd, when developing
the new version of the plugin. That's what I do. It does get a
bit iffy if your manifests want to fetch files from the puppetmaster
(i.e. that aren't in the "modules" namespace) though, or otherwise
need to access files that are only available on the puppetmaster.
Good news, though, is that the upcoming "Rowlf" version of Puppet is
supposed to solve this for at least resource types. At least Luke has
posted patches to the devel list that I gather will do that. But it
will probably still be a problem for custom functions (I have somewhat
volunteered to take a look at it, but I'm unlikely to find the time
before Rowlf is supposed to be out).
/Bellman
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
