Issue #7316 has been updated by Chris Price.
OK, I've played around with the config file and the multiple vardir settings, and have been able to reproduce and diagnose the error that Jeff described. There are a couple of things going on here. First of all, when you run a master and an agent on the same node, and they share the same confdir, then they will also share the same modulepath (unless you've explicitly overridden it). When you do an agent run the facts are synced to the agent libdir. Unfortunately, the autoloader looks in both the module path and the libdir for facts, so this would explain why Jeff saw the facts being loaded twice. This is annoying and stupid behavior, and Patrick and I have discussed on several occasions the fact that the autoloader should *never* load from the modulepath for any application other than 'master'; but it should be harmless in this case. (I will explain why in more detail below.) The second issue is that Jeff's config file uses *three* vardirs, not two. It uses a separate vardir for master, agent, and 'main'. If you do a "--configprint vardir" for either master or agent using his config file, you will see that these settings *are* being respected. The problem is that when you run "puppet help", your libdir is now the one specified in **main**, and NOT the one specified in agent. Since the faces / modules that you just synced down to the agent libdir are NOT in the libdir for the "help" application, bad things start to happen; because the autoloader can't find what it is looking for in the libdir, it starts looking in the modulepath. This is when you get the "no such file to load -- puppet/cloudpack". So, while it sucks that the autoloader is falling back to the module path (and that should eventually be fixed, as I mentioned above), the real issue here is that libdir is not set correctly. So what should be done about this? I can see a few options; they would all be relatively easy to implement, but each a bit clumsy in its own way. The first option is that we could force all applications (including help and other faces) to explicitly look for the "agent" vardir/libdir settings and prefer those over ones found in "main". This feels like a hack to me, but it would make Jeff's config file work as he expected. The second option would be to say that it is a configuration error to define a vardir or libdir in the "agent" section of the config file. You could still define them in both "main" and "master" if you really wanted the master to use separate paths from the other tools. Basically it makes sense for master to have its own libdir if desired, but all of the client-side tools need to share a libdir so it seems wrong to allow that to be configured in the "agent" section of the config file (since it applies more broadly than to just the agent). I believe that Jeff mentioned that this multiple-vardirs-in-the-same-puppet-conf file setup was how we ship PE out of the box. I had a look at the puppet.conf.erb file in the PE "dist" repo, and it does not look to me like that is actually the case. We only set 'vardir' once in that file; in the "main" section. This means that all puppet applications (master, agent, and all faces including 'help') will share the same vardir, and thus the same libdir. Therefore I do not believe that the issue that Jeff reported will occur; I expect synced faces to work properly (but have not tested that yet). ---------------------------------------- Bug #7316: puppet face applications (subcommands) delivered via pluginsync and as modules should work https://projects.puppetlabs.com/issues/7316#change-65505 Author: Dan Bode Status: Code Insufficient Priority: Urgent Assignee: Category: Faces Target version: 3.0.0 Affected Puppet version: Keywords: face faces subcommand application module plugin pluginsync Branch: https://github.com/puppetlabs/puppet/pull/571 If you deliver a new face that consists of: * application * face * action for face via pluginsync, then the application isn't actually found, and worse, it taunts you by showing it to you in the list of available subcommands. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" 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-bugs?hl=en.
