Title: Message Title
Henrik Lindberg commented on PUP-3896
Re: Big puppet modules should be able to ship there own versions of dependent modules
This has implications throughout the Puppet infrastructure. It is currently only possible to support different versions of logic/content that is used server side. There is no way to have different/multiple versions of facts, resource types, or providers because there is no way to encode this in the catalogs sent to agents.
The new loader system in Puppet 4.0 is used for loading 4x functions. These loaders only make functions visible to a module if it is from a module listed as a dependency of that module. For backwards compatibility the loaders will make everything on the modulepath visible to a module if the module metadata does not contain any dependencies at all (as opposed to have an empty dependency entry, in which case it gets no visibility into other modules).
The idea is to use these loaders to load other puppet objects as well (classes, defines, etc.). The 4x loaders can easily be modified to support additional module concepts, such as reexporting; one module A depends on another X, and makes it contents visible to those that depends on A (without those having to know anything about X).
While it is possible to support such extra features (re-export, and similar), the full extend of what is described in this epic requires new versions of the catalog, how resource types are implemented, and how they are stored in puppetdb. I really want the system to have full isolation between components like in Java OSGi, but I am afraid that the suggested 2w are however simply off by a factor of 30 to 100
Add Comment
This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit
