FAQ
From all the reading I have done, I have come to the conclusion that
'transaction' support is not offered in Puppet, in any of the predefined
language constructs (Specifically speaking of package). Our client has a
request that if one package declaration fails, all other package
declarations that were successful be rolled back, and the catalog run
immediately stop afterwards.

From what I can tell, the best approach to this is to run the puppet agent
with '--noop' prior to the actual run and check the return code. If it is
higher than 2, we have a potential issue. Does this sound correct?

Or is there some puppet magic recipe I am missing?

Thanks!
Birch

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Denmat at May 7, 2013 at 1:11 pm
    Hi,

    No, puppet is not transactionable. There is also no simple way to do it in puppet and running noop first is no guarantee that the run will succeed.

    Version control may help you out to 'roll back' but it would be messy depending on changes. Traditional methods of snapshoting disk or backup/restore can be wrapped around it (never done that myself).

    Rspec testing can help you out a bit in testing as of course so can other pre deployment testing.

    If the client doesn't like 'always roll forward' then puppet might not float their boat.

    Cheers,
    Den
    On 07/05/2013, at 10:17, James Birchfield wrote:

    From all the reading I have done, I have come to the conclusion that 'transaction' support is not offered in Puppet, in any of the predefined language constructs (Specifically speaking of package). Our client has a request that if one package declaration fails, all other package declarations that were successful be rolled back, and the catalog run immediately stop afterwards.

    From what I can tell, the best approach to this is to run the puppet agent with '--noop' prior to the actual run and check the return code. If it is higher than 2, we have a potential issue. Does this sound correct?

    Or is there some puppet magic recipe I am missing?

    Thanks!
    Birch
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jason Slagle at May 7, 2013 at 1:53 pm

    On 05/07/2013 09:13 AM, Denmat wrote:
    Hi,

    No, puppet is not transactionable. There is also no simple way to do it
    in puppet and running noop first is no guarantee that the run will succeed.

    Version control may help you out to 'roll back' but it would be messy
    depending on changes. Traditional methods of snapshoting disk or
    backup/restore can be wrapped around it (never done that myself).

    Rspec testing can help you out a bit in testing as of course so can
    other pre deployment testing.

    If the client doesn't like 'always roll forward' then puppet might not
    float their boat.

    Couldn't he just make the downstream packages depend on package he is
    gating with?

    You could even use a collector to add that package as a before to all
    other packages. However, this will not handle any dependencies that yum
    for instance may bring in - you'd have to model those independently.

    Jason

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at May 7, 2013 at 3:33 pm

    On Tuesday, May 7, 2013 8:13:39 AM UTC-5, denmat wrote:
    Hi,

    No, puppet is not transactionable. There is also no simple way to do it in
    puppet and running noop first is no guarantee that the run will succeed.
    And this isn't so much an issue with Puppet as with the underlying system
    tools. Depending on the circumstances and environment, package rollbacks
    may not even be possible. (For example, if the original package is no
    longer available from any of the configured repositories.) Also, to the
    extent that package management may trigger embedded scripts to run, those
    scripts cannot be un-run.

    With some effort, it should be possible to design your manifests so that
    package management progresses in a fixed sequence, and any failure along
    the way prevents further resource modifications, but rollback is another
    thing entirely.


    Version control may help you out to 'roll back' but it would be messy
    depending on changes. Traditional methods of snapshoting disk or
    backup/restore can be wrapped around it (never done that myself).
    Yes, I think that whether you use Puppet or some other tool, if you truly
    need to implement rollback then your best bet is to use file systems and
    underlying configuration supporting snapshotting, so that you can roll back
    by reverting to a snapshot. Do note that such an event would roll back the
    entire file system, however, which cannot safely be done to a live
    filesystem. You might be able to automate the process, but the system
    would need to be taken out of service while the reversion was performed.
    Any work in progress and any data not stored remotely would be lost.
    Furthermore, if the snapshot were recorded of a live system, then it is
    virtually certain that restoring it brings the filesystem to a state that
    is inconsistent with the then-running processes. The system may be able to
    recover from that without manual intervention, but it's not clean.


    Rspec testing can help you out a bit in testing as of course so can other
    pre deployment testing.

    If the client doesn't like 'always roll forward' then puppet might not
    float their boat.
    If all you really want to be able to roll back is the set of installed
    packages, then you could perhaps wrap Puppet in some custom fixture that
    records a complete package list before the run, with versions, recognize
    failed runs, and removes / downgrades packages afterward as necessary. Run
    that out of cron, instead of running the agent as a daemon.

    Really, though, that's a whole lot more trouble than it's likely to be
    worth. Were I you, I would try to talk the client down to something more
    manageable (and safer).


    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedMay 7, '13 at 12:17a
activeMay 7, '13 at 3:33p
posts4
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase