Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-3922

Preserve modulepath structure during pluginsync



    • Type: Bug
    • Status: Needs Information
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: PUP 5.y
    • Component/s: None
    • Labels:
    • Template:
    • Team:


      Original problem report from Ben Ford:

      I had a problem come up in training last week involving synced facts that brought out a larger problem in pluginsync.

      So if I create a module 'one' and define a fact in it called 'myfact', then create a module 'two' and also define a fact there called 'myfact' they will collide. The fact in 'two' will win because it comes later in the directory globbing. But worse is that they will be continuously fighting. On an agent run you can see this fact being overwritten to 'one/myfact' and then 'two/myfact' every single time.

      This is horrible for usability because it's not clear which fact will be called, and it's a terrible waste of bandwidth, etc.

      My comment from two years ago:

      The namespacing/load order is problematic but the files being copied on top of one another would be fixed if we replicated the module path structure from the master onto the client instead of squashing everything into $plugindest regardless of source.

      It turns out that this problem blocked our ability to execute on PUP-1077 and any related efforts to modularize things currently in Puppet core, because newer versions of a module which restructured files would, when pluginsync'ed, incompletely overlay the same module structure included in a package's modulepath.

      If we instead preserve the modulepath structure that the master discovers as it builds a file set for pluginsync and send the lib/ directories down to the agent with their module name prepended, the agent could detect that there was an overlapping module name and exclude the built-in one from its load path. This would ensure that the agent would only have one version of a module in its $LOAD_PATH. If we allow multiple versions of code in the $LOAD_PATH, then we will reintroduce problems like redmine 7316.




            eric.sorenson Eric Sorenson
            1 Vote for this issue
            9 Start watching this issue



                Zendesk Support