You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From choria-legacy/mcollective-choria#576, the -T collective option has been added to the federation application directly. When I try use this, it doesn't appear to override the main_collective setting in /etc/puppetlabs/mcollective/client.cfg.
I do something a little odd; I set a default collective of one that doesn't exist to force the admins to think about what collective they are sending the message to (rather than defaulting to our entire estate):
main_collective = deliberately_broken
[biguml@federator ~]$ mco federation trace nodename -v -T all
The federation application failed to run: Unknown collective 'deliberately_broken' known collectives are '...'
The environment variable MCOLLECTIVE_FED_COLLECTIVE also doesn't seem to work, but that may be a side affect of not importing all the mcorpc code, as you say.
The text was updated successfully, but these errors were encountered:
Can you show the backtrace please? I am guessing the configuration is initialized early and then a new client is made with the set collective - but by then its too late, help to see the backtrace
MCOLLECTIVE_FED_COLLECTIVE wouldnt help here thats something else
Unknown collective 'deliberately_broken' known collectives are '... ... ...' (RuntimeError)
from /opt/puppetlabs/puppet/lib/ruby/gems/2.5.0/gems/choria-mcorpc-support-2.21.1/lib/mcollective/util.rb:237:in `make_subscriptions' <----
from /opt/puppetlabs/puppet/lib/ruby/gems/2.5.0/gems/choria-mcorpc-support-2.21.1/lib/mcollective/client.rb:93:in `subscribe'
from /opt/puppetlabs/puppet/lib/ruby/gems/2.5.0/gems/choria-mcorpc-support-2.21.1/lib/mcollective/client.rb:87:in `createreq'
from /opt/puppetlabs/puppet/lib/ruby/gems/2.5.0/gems/choria-mcorpc-support-2.21.1/lib/mcollective/client.rb:171:in `req'
from /opt/puppetlabs/mcollective/plugins/mcollective/application/federation.rb:43:in `trace_node'
from /opt/puppetlabs/mcollective/plugins/mcollective/application/federation.rb:155:in `trace_command'
from /opt/puppetlabs/mcollective/plugins/mcollective/application/federation.rb:229:in `main'
from /opt/puppetlabs/puppet/lib/ruby/gems/2.5.0/gems/choria-mcorpc-support-2.21.1/lib/mcollective/application.rb:283:in `run'
from /opt/puppetlabs/puppet/lib/ruby/gems/2.5.0/gems/choria-mcorpc-support-2.21.1/lib/mcollective/applications.rb:23:in `run'
from /opt/puppetlabs/puppet/lib/ruby/gems/2.5.0/gems/choria-mcorpc-support-2.21.1/bin/mco:33:in `<top (required)>'
from /usr/bin/mco:23:in `load'
from /usr/bin/mco:23:in `<main>'
ripienaar
transferred this issue from choria-legacy/mcollective-choria
Jan 4, 2021
From choria-legacy/mcollective-choria#576, the
-T collective
option has been added to the federation application directly. When I try use this, it doesn't appear to override themain_collective
setting in/etc/puppetlabs/mcollective/client.cfg
.I do something a little odd; I set a default collective of one that doesn't exist to force the admins to think about what collective they are sending the message to (rather than defaulting to our entire estate):
The environment variable MCOLLECTIVE_FED_COLLECTIVE also doesn't seem to work, but that may be a side affect of not importing all the mcorpc code, as you say.
The text was updated successfully, but these errors were encountered: