Exec[create-mcollective-metadata] in mcollective::server::config::factsource::yaml never runs for mcollective>=2.5.0

[wilrnh]

Exec[create-mcollective-metadata] in mcollective::server::config::factsource::yaml never runs for mcollective>=2.5.0. At least from the Puppetlabs repo. mcollective=2.0.0 from ubuntu (trusty) does not have this issue.

This is because the Exec uses$mcollective::yaml_fact_path_real to determine if it should run, via the creates attribute. The Puppetlabs MCollective packages automatically creates that file post-install, however, thus denying the Exec the chance to run. As a result, facts aren't available to MCollective until the next time the Cron[refresh-mcollective-metadata] is run.

Not sure how to tackle this issue, but I'd be OK with the Exec running only via a Refresh event from mcollective::server::setting{factsource}

[wilrnh]

Let me know what you guys thing so I can push a patch up.

[ffrank]

Thanks for the succinct writeup.

I have strong reservations agains refreshonly. If there is any clean way for the agent to determine system state and make a decision, we should absolutely prefer that, at least within the boundaries of acceptable effort/maintainability.

[igalic]

@ffrank could you please elaborate on your reservations towards refreshonly?

[ffrank]

• agent crashes make you lose signals
• intermittent errors in signaled resources make you lose signals
• failing dependencies of signaled resources make you lose signals (if this bug is fixed in your Puppet version)

etc.

This is more than inconvenient, because Puppet has no way to recover from this half-configured state. Human intervention (reset the system to de-sync a signaling resource) becomes necessary. The specifics of doing this are seldomly intuitive without diving into the module's code.

[igalic]

thank you ♥ for the 💔 explanation.

[madAndroid]

We're experiencing this as well, and I agree with @ffrank's sentiments about refreshonly => true ... would it perhaps be worth writing a file as a flag, as part of the exec, and then pointing creates => at this flag? I've taken this approach in instances such as this, where there isn't another way to determine whether the exec has been run.

[jyaworski]

Hello:

Is this still needed?

[ffrank]

Thanks for the hint @madAndroid. This isn't a convenient option here, because the module does not own the script. (Sure, we could create the marker file from the exec itself, but oh well...)

So, principles aside, I guess we can get away with falling back to refreshonly after all. If the command fails or is not run for any reason, Puppet will still install the cron job and the user is stuck with waiting for that to run.