If a custom fact which does not compile has been copied to the client, puppetd will fail instead of trying to resync the fact again.

steps to reproduce, edit one of the custom facts (on the client, not on the server), and “break it”. try to run puppet and puppet will fail to load the fact and exit.

ideally, puppet should check if there is a new version of the fact in case that it cant run it.

To be clear, the problem here is that you’ve got code to produce a fact value, and that code is somehow invalid, which is cause Facter to fail, which is in turn causing puppetd to fail. Right?

In that case, there are two bugs — one in Puppet (puppetd should be resilient to failures in Facter) and one in Facter (it should be resilient to broken facts).

Either way, though, it would be hard to have this kind of failure result in an automatic resyncing of the fact code, and, really, that wouldn’t normally fix the problem — it just pulled down broken code, and it’s reasonable to assume that, seconds later, the code is still broken.

The only reasonable response here is to cache the facts locally and pass them back up again; or, with more recent versions, the server can use its cached facts for the client.

luke wrote:

To be clear, the problem here is that you’ve got code to produce a fact value, and that code is somehow invalid, which is cause Facter to fail, which is in turn causing puppetd to fail. Right?

Right

In that case, there are two bugs — one in Puppet (puppetd should be resilient to failures in Facter) and one in Facter (it should be resilient to broken facts).

Either way, though, it would be hard to have this kind of failure result in an automatic resyncing of the fact code, and, really, that wouldn’t normally fix the problem — it just pulled down broken code, and it’s reasonable to assume that, seconds later, the code is still broken.

well, the main problem is that puppetd will never run again on this machine unless you manually remove the fact, so ideally, puppet should try to check once in a while if the fact has changed on the server.

The only reasonable response here is to cache the facts locally and pass them back up again; or, with more recent versions, the server can use its cached facts for the client.

I would suggest that puppet

do not fail when facter fails, worst case you get a compile error because of a missing fact.¶

puppet resync facts if facter fail (which is almost the same like today when you have factsync, e.g. puppet syncs the facts and reloaded after factsync).¶

I think that have a cache of facts is way too complex for this problem… and not needed, I don’t really wants my clients to compile something with broken facts, i just want an automated way to fix it if it happens (e.g. resync of the new good facts).

ohadlevy wrote:

well, the main problem is that puppetd will never run again on this machine unless you manually remove the fact, so ideally, puppet should try to check once in a while if the fact has changed on the server.

Really? I would expect the fact syncing to still work, even if there are broken facts. That’s not the case right now?

I would suggest that puppet

do not fail when facter fails, worst case you get a compile error because of a missing fact.¶

I actually think the run probably should fail if Facter fails — I think most people would agree it’s better to fail than to compile with incomplete information.

puppet resync facts if facter fail (which is almost the same like today when you have factsync, e.g. puppet syncs the facts and reloaded after factsync).¶

We should be resyncing facts anyway, so I don’t see how this helps or hurts. We should resync facts on every run, regardless of whether they’re working or not.

Can you confirm that a broken fact causes factsync and/or pluginsync not to work any longer?