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.
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 <jbirchfield@missiondata.com> 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.
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.
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.