Project

General

Profile

Actions
Copy link

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 almost 12 years ago. Updated almost 10 years ago.

Status:
Rejected
Priority:
2
Assignee:
Nicolas CHARLES
Category:
Techniques
Target version:
2.3.13
Pull Request:
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
Copy link
 #1

Updated by Matthieu CERDA almost 12 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
Copy link
 #2

Updated by Matthieu CERDA almost 12 years ago

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

Updated by Jonathan CLARKE almost 12 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
Copy link
 #4

Updated by Matthieu CERDA almost 12 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
Copy link
 #5

Updated by Nicolas CHARLES almost 12 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
Copy link
 #6

Updated by Nicolas CHARLES almost 12 years ago

  • Status changed from Discussion to 8
Actions
Copy link
 #7

Updated by Matthieu CERDA almost 12 years ago

  • Target version changed from 2.3.10 to 2.3.11
Actions
Copy link
 #8

Updated by Matthieu CERDA over 11 years ago

  • Target version changed from 2.3.11 to 2.3.12
Actions
Copy link
 #9

Updated by Matthieu CERDA over 11 years ago

  • Target version changed from 2.3.12 to 2.3.13
Actions
Copy link
 #10

Updated by Nicolas CHARLES over 11 years ago

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

Updated by Nicolas CHARLES over 11 years ago

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

Actions
Copy link
 #12

Updated by Nicolas CHARLES over 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
Copy link
 #13

Updated by Nicolas CHARLES over 11 years ago

  • Status changed from In progress to Rejected
Actions
Copy link
 #14

Updated by Benoît PECCATTE almost 10 years ago

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

Also available in: Atom PDF