Thanks for the replies so far from all. It does seem like it is both a problem with the fact that I decided to explicitly version our application modules and provide a mechanism for tieing configuration "blueprints" in the ENC side to the version of the application module in use, but no such mechanism for our common modules which naively I had expected to remain relatively static.
So the ultimate solution may be to provide versioning in a similar way, but by utilising the class interface specifications already generated by introspection. I'm not sure what I would get from resource_type in addition to what I already have, since it means some additional work for every class to be called... surely there will be a performance overhead. The only remaining question is how to then tie configuration data which now is the only static data coming into the ENC from the user, with the class interfaces coming from the Puppet code. I expect I'll puzzle over this over the next week and report back ;) -- 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 puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
