We're thinking about solutions to the environment isolation problem described in https://tickets.puppetlabs.com/browse/SERVER-94. The short version is that during compilation, the master will load resource types from the environment for that agent (these are resource types defined in ruby and often distributed as modules, not types defined in the puppet language). This results in a `Puppet::Type::Foo` ruby class being defined and loaded into the master's ruby runtime. Bad things happen when multiple versions of the type exist in different environments, as only one version of the class can be defined in the ruby runtime at any one time.
Part of the difficulty is that custom types contain master and agent logic in the same file, e.g. lib/puppet/type/foo.rb. For example, newproperty/newparam/newvalues define the "shape" of the custom type and are needed during compilation. But methods like validate, munge, etc are evaluated at catalog application time. Plus there has historically been some confusion about what code is evaluated where, for a variety of reasons. To help shed some light on that, I've created the following document in the form of a PR to the puppet-specifications repo: https://github.com/puppetlabs/puppet-specifications/pull/72. The goal is to specify the current behavior for custom types, and especially understand which parts of the types affect catalog compilation. Feedback is welcome. Josh -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/6bfb0f2b-7a72-411d-9bff-7ccc240dcdb7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
