[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by eric sorenson. Priority changed from Normal to High Bug #7316: puppet face applications (subcommands) delivered via pluginsync and as modules should work https://projects.puppetlabs.com/issues/7316#change-74124 Author: D

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by eric sorenson. Assignee set to eric sorenson Keywords changed from face faces subcommand application module plugin pluginsync to face faces subcommand application module plugin pluginsync backlog Bug #7316: puppet face ap

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by Andrew Parker. Target version changed from 3.0.x to 3.x Merged into master so that we get into 3.1.0. This is a larger change than just a simple bugfix. Merge in commit

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by Jeff McCune. I've also filed #16651 which specifically calls out the bug we've introduced (or rather failed to fix?) in 3.0.0. I think a new bug is warranted because we're explicitly breaking existing functionality on the node subcommand, which is a subtlety no

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by Jeff McCune. I think the current problem is just my overlooking a method that needs to be changed when resolving the merge conflicts. As soon as I get of BART and situate in the hotel I'm going to find out for sure. I don't think there's a "big" issue here, just

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by Chris Price. Jeff, If you directly check out the final relevant commit of my original pull request: https://github.com/cprice-puppet/puppet/commit/860d2ef79f7ee0629d76273a710169b8a5b2d31a and then try loading faces from the modulepath, does it work properly? B

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by Jeff McCune. @eric, @andy The first (dirty but "working") pass at making faces work is published in topic branch fix/3.x/7316_load_faces_from_modulepath. ---

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by eric sorenson. I should comment too that I do not think the situation I outlined above is ideal, nor is it the absolute final word on this issue -- on one level it seems absurd that something as fundamental as loading code is this difficult, but tons of smart p

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by eric sorenson. Daniel Pittman wrote: > So, to make sure I understand: we can no longer send faces or any other > complex plugin to the Puppet agent with PluginSync - instead they need to be > shipped as full modules, even though the agent doesn't use them? more

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by Daniel Pittman. eric sorenson wrote: > This bug as it's titled is only half correct; pluginsync turns out to be a > bad way to deliver faces and other complex plugins. Modules are indeed > supported for loading faces, and loading faces from the modulepath works

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by eric sorenson. Assignee set to eric sorenson Bug #7316: puppet face applications (subcommands) delivered via pluginsync and as modules should work https://projects.puppetlabs.com/issues/7316#change-68735 Author: Dan Bode

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by Chris Price. One other minor update: during discussions around this ticket it was mentioned that we may have introduced a possible regression with respect to loading facts multiple times. I think that the relevant tickets on that topic are #12464, #3741, #1231

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

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

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by Chris Price. Putting aside the issue with the config file specifying alternate vardirs for a moment (this is a valid issue that we need to address): When running both master and agent/client with explicit "--confdir" and "--vardir" options (pointing to separate

Re: [Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

On Wednesday, June 20, 2012, wrote: > Issue #7316 has been updated by Chris Price. > > > I just attempted to reproduce this, and everything worked fine for me. I > am *not* mirroring Jeff’s setup with respect to trying to set a separate > vardir for master and agent (yet); there is a decent chan

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by Chris Price. Now that I'm past the gem stuff, I'm getting this: Error: Could not autoload puppet/face/node_aws/create: "--tags=": already defined in puppet This is a known issue that was discussed at length in an e-mail thread; it was decided that face

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by Jeff McCune. Assignee deleted (Chris Price) I'd like to make sure this issue has properties set such that the 3.0 release is blocked until this is resolved. Are all of the fields set correct for this to happen? (I think it's just the target version field and t

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by Chris Price. correct. we won't be loading from the module path. Bug #7316: puppet face applications (subcommands) delivered via pluginsync and as modules should work https://projects.puppetlabs.com/issues/7316#change-5544

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by eric sorenson. Assignee set to Nick Lewis 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. :) Bu

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by Nigel Kersten. I'm not sure what actual decision is left here for me to make. * We don't need to support loading apps from modules on a master that haven't been pluginsynced to the local agent * We do need to play well with environments * We do need to wor

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by Nick Lewis. So to clarify before I get myself further entangled in this mess: is it actually a requirement that we be able to run applications from the modulepath on the master without first having pluginsunc them? I guess the case where this matters is a maste

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by Nigel Kersten. 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. Bug #7316: puppet face app

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by Nick Lewis. Assignee changed from Kelsey Hightower to Nick Lewis 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 t

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by Kelsey Hightower. Assignee changed from Nick Lewis to Kelsey Hightower Bug #7316: puppet face applications (subcommands) delivered via pluginsync and as modules should work https://projects.puppetlabs.com/issues/7316 A

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by Jeff McCune. Affected Puppet version deleted (2.7.0rc1) 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 nod

[Puppet - Bug #7316] puppet face applications (subcommands) delivered via pluginsync and as modules should work

Issue #7316 has been updated by Jeff McCune. Subject changed from puppet applications delivered via pluginsync don't work. to puppet face applications (subcommands) delivered via pluginsync and as modules should work # Modules # Since #9018 was closed as a duplicate of this, I just want to ma