Project

General

Profile

Actions

Bug #3121

closed

Post-modification hook in "download a file from shared folder" technique runs no matter if copy is successful or not

Added by Arthur ANGLADE about 11 years ago. Updated about 9 years ago.

Status:
Rejected
Priority:
2
Category:
Techniques
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

Description

the Post-modification hook in the "download a file from shared folder" technique is run, even if the file copy is not done.

Actions #1

Updated by Matthieu CERDA about 11 years ago

  • Status changed from New to Discussion
  • Priority changed from N/A to 2

Hum, you were not using the Technique correctly, you were not using a path in shared-files on the Rudder server in the associated directive. However, I found out a reporting issue while testing it too :D

The non convergeance of the post hook execution was because the Technique execution was copying a wrong file over and over again.

Jon, Can you please reject this bug ?

Actions #2

Updated by Matthieu CERDA about 11 years ago

  • Assignee changed from Matthieu CERDA to Jonathan CLARKE
Actions #3

Updated by Jonathan CLARKE about 11 years ago

  • Assignee changed from Jonathan CLARKE to Matthieu CERDA

Arthur's bad use of the Technique is irrelevant to the fact that this is probably a bug... Please check again.

Actions #4

Updated by Matthieu CERDA about 11 years ago

Oops, I explained it wrong.

I tested the Technique with a voluntarily wrong copy path, and I saw nothing that should not happen:

Can't stat /var/rudder/configuration-repository/shared-files/ermagherd/azeaze/ in files.copyfrom promise
R: @@copyFile@@result_error@@28031429-5320-4ec5-812a-17b9ca8dfffb@@8e24507b-cff5-4d68-b5ae-2dcc52930804@@5@@Copy file@@ermagherd/azeaze/@@2013-01-02 14:51:02+01:00##72b8eff1-e5df-4c58-8b48-ce390d5ce74b@#The content or permissions of the file(s) could not have been repaired for some reason

The copy fails as expected, and no post-hook is run.

The following CFengine code prevents the post-hook to be executed in case of a copy failure:

ifvarclass => "execute_command_$(index).copy_file_$(index)_modified.!copy_file_$(index)_failed",

The post-hook execution should only happen if:
  • A post-hook has been given and asked to be executed
  • The destination file / directory has been updated
  • The copy has not failed

There is therefore nothing wrong for me ?

Actions #5

Updated by Nicolas CHARLES about 11 years ago

I've been toying with this bug, and found out that :
  1. if the copy fails AND
  2. the destination files doesn't exist yet

then there are no reports generated for the Post-modification hook component

every other case seem covered

Actions #6

Updated by Nicolas CHARLES about 11 years ago

  • Status changed from Discussion to 8
Actions #7

Updated by Matthieu CERDA about 11 years ago

  • Target version changed from 2.3.10 to 2.3.11
Actions #8

Updated by Matthieu CERDA almost 11 years ago

  • Target version changed from 2.3.11 to 2.3.12
Actions #9

Updated by Matthieu CERDA almost 11 years ago

  • Target version changed from 2.3.12 to 2.3.13
Actions #10

Updated by Nicolas CHARLES almost 11 years ago

  • Status changed from 8 to In progress
  • Assignee changed from Matthieu CERDA to Nicolas CHARLES
Actions #11

Updated by Nicolas CHARLES almost 11 years ago

This is on version 1.3 (the only version with posthook)

Actions #12

Updated by Nicolas CHARLES almost 11 years ago

Ok, so there is two problem with this techniques, because mixing copy_from and perms can result in surprising outcome (like kept for perms and failed for copy) :
  1. if the copy fails, but the permission is modified, then there is no reports
  2. if the file was valid, but had its permission changed, then the posthook is run (like for instance if you have conflicting promises)

For the second point, there isn't much that can be done (and I suspect its whats happening on this bug report)
For the first point, there is a new ticket http://www.rudder-project.org/redmine/issues/3583

So I'm rejecting this ticket

Actions #13

Updated by Nicolas CHARLES almost 11 years ago

  • Status changed from In progress to Rejected
Actions #14

Updated by Benoît PECCATTE about 9 years ago

  • Project changed from 24 to Rudder
  • Category changed from Techniques to Techniques
Actions

Also available in: Atom PDF