On Mon, 6 Jul 2015, John Bollinger wrote:
I like that pretty well. If Puppet moved in this direction, though, then it would be nice to protect against "last known good" turning out to not be so good after all by making it a blessed configuration that has actually proven good. That way, if a fresh code deployment turns out to be bad then there is a genuine known good configuration that can quickly be restored. In other words, I'm suggesting three configurations instead of two: undeployed, deployed, and known good.
Is that really the domain of the compiler/catalog cache, though? Seems more like the purview of the code testing and promotion workflow, because it requires a test/feedback/fix interaction loop, not an on/off flag.
Eric Sorenson - eric.soren...@puppetlabs.com - freenode #puppet: eric0 puppet platform // coffee // techno // bicycles
