Hi all,
As promised, here's my follow-up to the email on caching.
Almost since its creation, Puppet has attempted to avoid recompiling
its catalog when possible. I think I originally did this as an
optimization, and I'm beginning to think I've been holding onto this
feature for no good reason.
Turns out that it kinda broke sometime in 0.24. The catalog gets
recompiled every time anyway. What I'm trying to do right now is
figure out whether it's worth trying to fix that, or if I should just
carve out the code that does this.
As an aside, I think the bit that's broken is that the client is not
correctly caching its facts, so it's always comparing facts against an
old version, so they've always changed, which always forces a
recompile. That bit should probably be fixed.
Upside of carving it out:
No more worries about why the heck the catalog isn't being
recompiled. I've had lots of bugs filed against this -- it's not
picking up new files, it's not noticing changes in my external node
store, it's not noticing changes in facts, etc. These bugs magically
go away (well, they're already gone, but no worries about more
appearing).
Less code is always good when reasonable. In this case, there's a
good bit of infrastructure around knowing if we should recompile (see
below).
No premature optimization -- if we don't need to avoid recompiling, we
shouldn't.
Downside:
Compiling is relatively expensive, especially when using stored
configs. In most cases, the configuration hasn't changed, so it ends
up being a lot of wasted effort. It doesn't really feel like a
premature optimization, considering the potential savings.
So, question 1: Do we just get rid of selective recompiling? If so,
then you can stop reading. :)
Here's how the selective recompiling works right now:
The client collects its facts and compares them to the facts it cached
last time; if they've changed, it recompiles.
The client asks the server for the "version" of the configuration it's
currently running. The client compares this timestamp to the
timestamp of its configuration. If the server's timestamp is later,
then the client recompiles.
The server calculates the configuration version as the later of the
last parse time, the timestamp of the client's facts, and the
timestamp of the node configuration. (Well, this is actually a lie --
the current code ignores the node and fact info; this is the code that
is in place but not yet used.) This would work if we were sticking to
versions for things like nodes and facts, but (as my last email
explained) we're using TTLs for them instead.
How selective recompiling *could* work:
In the switch to TTLs, the server could rely on the expiration date of
the node and facts -- if either is expired, then a recompile is
forced. This doesn't really make sense, though, because you'd
normally just set the ttl to the runinterval, which means they'd
automatically expire after 30 mins, forcing a recompile every time.
So, this would only work if you tuned the ttl higher.
You could just ignore the server's node and fact information,
continuing to rely on the time of the last parse: If the client's
catalog is older than the last parse, recompile. I can basically
guarantee this will cause all kinds of problems, though, because of
external node sources.
I'm leaning toward just getting rid of this feature entirely.
Any dissenters? Is there anything I'm missing?
--
Basic research is what I am doing when I don't know what I am doing.
--Wernher von Braun
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
