Nigel, I don’t know if we want to support this or not, but it is a genuine issue. The Faces code doesn’t make substantial effort to massage the module path into the Ruby load path, and uses only the later to try and locate code.

Given we extensively use require for loading, not having those library directories on the Ruby load path will require substantial extra work, as well as reimplementing the require mechanism ourselves.

On the other hand, obviously we don’t already put the lib directories on the module path into the Ruby load path, so I don’t know what side-effects that change might have on the system; that makes me nervous about putting this into the RC series for 2.7, and about putting it in post-2.7.0, since both of those might be the worst choice depending on what assumptions this tripped up.

I actually think this is a higher priority – not only does pluginsync partially work giving you the disappointing illusion that things are okay :) But without it Faces are very manual to deploy and can’t really be developed and shared – which seems to defeat some of their purpose. YMMV. :)

Modules¶

Since #9018 was closed as a duplicate of this, I just want to make sure it’s clear that a solution to this ticket requires that puppet stand alone with a modulepath set correctly should also find the face application sub-commands. That is to say, the scope of this ticket is NOT simply limited to pluginsync.

Nick,

I’m trying to plan the remaining work for Cloud Provisioner in CK and this ticket impacts my work in that I may or may not be able to implement additional subcommands (application) beyond “puppet node” if this is resolved in 2.7.4.

Are you in a position to estimate if this ticket will be resolved in 2.7.4 or not?

Thanks, -Jeff

I’m working on this now. Making applications loadable is fairly straightforward, although there’s some weird issues around setting modulepath and libdir, because we can’t use the config file for those settings (because we don’t have a runmode, so where do we look?). Also, naturally, applications need to be run as a user that can read them. This means on the master they need to be run as root or the user the master runs as, and on the agent, they probably need to be run as root.

While applications are loadable from modules, loading the faces on which they depend is proving much more difficult. The main problem is that we don’t allow actions to be redefined, so we can’t load a face or action more than once, so we use require. But require is out of our control as far as module path goes. We could require via the autoloader, but that would necessarily use the absolute path, which doesn’t do anything to prevent multiple loading in the case where the file IS in the regular load path, and gets required again with its relative path. Unfortunately, because faces are a public API, this is a real concern. Requiring an action would autoload the face, which would autoload the action and we get a conflict.

The closest thing to a solution I’ve got as yet is to add a hook to the modulepath setting to populate the load path with the lib dir of every module in each directory of the modulepath. Unfortunately, that doesn’t play well with environments, and would also mean that if a module is added, we wouldn’t find it until at least the filetimeout (when we refresh the modulepath).

Alternatively, we could have a mechanism to “pluginsync” the contents of module libs into the libdir, which would greatly simplify the situation.

Nigel Kersten wrote:

Great update Nick. Just pointing out that not playing well with environments is a huge problem, and I’d like to have a chat in person if that’s the only feasible solution we have.

After some discussion, it sounds like this is more complex: for a master/agent model it shouldn’t be using content from modules before they are pushed to the system with pluginsync. (That also helps address the case of environments, where you might have different versions of the same application in multiple environments.)

There might be some complexity around the puppet apply case, where we don’t do pluginsync, but we do want to see some code from modules. That, fairly obviously, doesn’t apply to other top level commands in Puppet though. (…as, if we are running apply we can’t also be running something else. :)

I have assigned this back to Nigel for now, since he can’t work out the details today…

Thanks. That seems to cover any questions – perhaps just a restatement was all that was needed. :)

Triage-a-thon: This is Accepted, marked as Urgent, and target for 2.7.x even — but has no Assignee. Sending it to Nick as he seems to be the one doing the actual work here. :)

This isn’t actually fixed yet. Pull request 518 ( https://github.com/puppetlabs/puppet/pull/518 ) was merged, but that just contains a (failing) acceptance test that I wanted to get in in case anyone else besides myself was looking at this ticket.