The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Feature #3806

Atomic Puppet

Added by Trevor Vaughan almost 4 years ago. Updated about 1 year ago.

Status:AcceptedStart date:05/19/2010
Priority:NormalDue date:
Assignee:Charlie Sharpsteen% Done:

0%

Category:transactions
Target version:-
Affected Puppet version: Branch:
Keywords:atomic transactions customer

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This ticket may be automatically exported to the PUP project on JIRA using the button below:


Description

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.

Basically:

(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!


Related issues

Duplicated by Puppet - Feature #21022: Notifications should be durable Duplicate

History

#1 Updated by Dan Bode almost 4 years ago

after discussing this with Trevor, I think the only type of resource action that would need to be tracked are pending refresh actions. Everything else should be able to resolve correctly just with another puppet run.

#2 Updated by James Turnbull almost 4 years ago

  • Category set to transactions
  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Luke Kanies

#3 Updated by James Turnbull over 3 years ago

  • Affected Puppet version deleted (development)

Luke – bump.

#4 Updated by Luke Kanies over 3 years ago

  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Luke Kanies)

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.

#5 Updated by James Turnbull over 3 years ago

  • Status changed from Accepted to Needs Decision
  • Assignee set to Nigel Kersten
  • Target version set to 2.7.x

#6 Updated by Nigel Kersten over 3 years ago

  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Nigel Kersten)
  • Target version deleted (2.7.x)

#7 Updated by Daniel Pittman over 2 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.

#8 Updated by Charlie Sharpsteen about 1 year ago

  • Assignee set to Charlie Sharpsteen

#9 Updated by Charlie Sharpsteen about 1 year ago

  • Keywords changed from atomic transactions to atomic transactions customer

Also available in: Atom PDF