On Apr 21, 2009, at 10:24 AM, Nigel Kersten wrote:
>
> so while you can specify a pluginpath for a specific environment, or
> you can simply create a module called 'plugins' for an environment
> that contains all the plugins in the files subdirectory, if I
> understand things correctly, we don't truly have separate plugins per
> environment.
>
> We find we have to create a symlink in the puppetmasterd libpath to
> one of the plugin sources we're delivering, otherwise while the
> clients can retrieve the plugins, the server doesn't "know" about the
> types and the manifest compilation fails.
>
> This doesn't seem ideal, as it makes it difficult to use environments
> as a release process, given that you may have a completely different
> version of plugin 'foo' in:
>
> /path/to/an/environment/plugins/source/foo.rb
> /path/to/puppetmasterd/libpath/foo.rb
>
> which I assume will affect the compilation server side...
>
> Am I missing something here?
>
> Is it at all feasible to instead have the puppetmasterd add the
> environment plugin source to the load path before compilation and
> remove it afterwards rather than relying upon the local puppetmasterd
> libpath? Or have things changed so much in 0.25 that this isn't an
> issue? (I'll test out 0.25 today, but thought I'd fire this off first)
This is essentially not feasible, because at this point the plugin
scope is always global. I mean, you could do this load/unload thing,
but it wouldn't have an affect beyond the first load.
To fix this, we need to move all of the global scopes -- types,
providers, functions, etc -- into environment-specific (or, more
generally, some kind of non-global) scopes.
This would be pretty hard, given the current way that types and
providers are implemented -- they're classes, and everything about how
we use them implies globalness.
I've got some basic plans laid for refactoring this whole mess, and
now that 0.25 is actually on the verge (commited my last code for rc1
last night), I can move beyond the REST switch and start thinking
about the other interesting stuff to do, so maybe this will make it in
soon.
I've got a customer who will hopefully fund a lot of the necessary
refactoring, toward creating a pure ruby interface (which would sit
alongside Puppet's language as a complement), but that's still a ways
away.
So, at this point, if you really want plugins in environments, use
different processes, unfortunately. Or, help me fix them. :)
--
A computer lets you make more mistakes faster than any invention in
human history--with the possible exceptions of handguns and tequila.
-- Mitch Ratcliffe
---------------------------------------------------------------------
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
-~----------~----~----~----~------~----~------~--~---
