The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
|Assignee:||Charlie Sharpsteen||% Done:|
|Affected Puppet version:||Branch:|
|Keywords:||atomic transactions customer|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
Per the mailing list:
I thought I’d toss this idea out here to get pointed and laughed at before I Redmine’d it.
I ran into the fun situation recently where I needed puppet to be more atomic.
(A) Update file –> (B) Restart Service
But…for some reason puppet got interrupted precisely between A and B!
So, the next time puppet ran, my system wasn’t in the state that I had described, instead the file had been updated but the service had not been triggered.
This got me thinking about the concept of atomic puppet updates. It shouldn’t be too difficult to write to disk/register the state of the operations as they happen and to be able to pick back up by default if a run is interrupted.
I say this, of course, completely tongue-in-cheek as the last graph discussion I jumped into went on for tons of messages!
#4 Updated by Luke Kanies about 5 years ago
- Status changed from Needs Decision to Accepted
- Assignee deleted (
I’m fine with this feature, but it’s actually a good bit of work.
We would basically have to record the entire set of event queues, and only empty them when the service is restarted or whatever.
This does play nicely into our goal of supporting more asynchrony, with direct integration into something like AMQP, but it’s still a ways away, I think.
#7 Updated by Anonymous about 4 years ago
Luke Kanies wrote:
We would basically have to record the entire set of event queues, and only empty them when the service is restarted or whatever. This does play nicely into our goal of supporting more asynchrony, with direct integration into something like AMQP, but it’s still a ways away, I think.
On review, we concur with this: this is a highly desirable outcome, and Puppet should be able to work nicely even if interrupted. We don’t really want to invent the wheel of keeping this persistent state ourselves, though, and given we have a strategy that would attach Puppet to an existing, persistent queue (eg: AMQP asynchronous Puppet, or whatever), better to hold off action until then.