Project

General

Profile

Actions

Architecture #15783

closed

User story #6099: We should be able to call actions as many times as we want

Make class_prefix unique

Added by Félix DALLIDET over 4 years ago. Updated about 2 years ago.

Status:
Resolved
Priority:
N/A
Category:
Generic methods
Target version:
Effort required:
Medium
Name check:
To do
Fix check:
To do
Regression:

Description

With the technique editor, the big idea is to define techniques that can be decline in multiple directives.
One of the problem is: if we have the same call made to a generic method, it will most likely be ignored at execution time by cfengine. Leading to broken reporting and
no easy way to properly what was executed on the system.

Since in Rudder, one directive is ALWAYS bond to only one technique, we could use the directive_id as key differentiator between each policy applied.
Which means that every call to a rudder logger or pure cfengine promise should be followed by a comment based on the directive id.

See:

    commands:
        "${command}" 
          contain => in_shell,
          classes => classes_generic_return_code_list_two("${old_class_prefix}", "${class_prefix}", @{kept_list}, @{repaired_list}),
          comment => "${report_data.directive_id}";

And

usebundle  => _log_v3("Execute the command ${command}", "${command}", "${old_class_prefix}", "${class_prefix}", @{args}),
comment => "${report_data.directive_id}";

This way every directive will be forced to execute its promises and reports on it, even if the exact same one was already evaluated sooner in the process.
But every exact same call will produce classes based on the same element which make reporting undoable. To avoid this we should also base the resulting classes
of each GM on the directive id
.

Where:

        "old_class_prefix"  string => canonify("command_execution_result_${command}");
        "args"               slist => { "${command}", "${kept_codes}", "${repaired_codes}" };
        "report_param"      string => join("_", args);
        "full_class_prefix" string => canonify("command_execution_result_${report_param}");
        "class_prefix"      string => string_head("${full_class_prefix}", "1000");

will become:

        "old_class_prefix"  string => canonify("${report_data.canonified_directive_id}_command_execution_result_${command}");
        "args"               slist => { "${command}", "${kept_codes}", "${repaired_codes}" };
        "report_param"      string => join("_", args);
        "full_class_prefix" string => canonify("${report_data.canonified_directive_id}_command_execution_result_${report_param}");
        "class_prefix"      string => string_head("${full_class_prefix}", "1000");


Subtasks 2 (0 open2 closed)

User story #15784: Base log on the directive id and add a canonified directive id in report_dataReleasedNicolas CHARLESActions
Bug #16078: Applying directives using the exact same GM with same parameters will always result in missing reportsResolvedAlexis MoussetActions
Actions #1

Updated by Félix DALLIDET over 4 years ago

  • Status changed from New to In progress
  • Assignee set to Félix DALLIDET
Actions #2

Updated by Félix DALLIDET over 4 years ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from Félix DALLIDET to Nicolas CHARLES
  • Pull Request set to https://github.com/Normation/ncf/pull/1068
Actions #3

Updated by Félix DALLIDET over 4 years ago

  • Pull Request deleted (https://github.com/Normation/ncf/pull/1068)
Actions #4

Updated by Félix DALLIDET over 4 years ago

  • Pull Request set to https://github.com/Normation/ncf/pull/1070
Actions #5

Updated by Félix DALLIDET over 4 years ago

  • Pull Request changed from https://github.com/Normation/ncf/pull/1070 to https://github.com/Normation/ncf/pull/1071
Actions #6

Updated by Vincent MEMBRÉ over 4 years ago

  • Tracker changed from User story to Architecture
  • Suggestion strength deleted (Require - I need this to use Rudder as I intend)
  • User visibility deleted (Infrequent - complex configurations | third party integrations)
Actions #8

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 5.0.14 to 5.0.15
Actions #10

Updated by Vincent MEMBRÉ over 4 years ago

  • Target version changed from 5.0.15 to 5.0.16
Actions #11

Updated by Alexis Mousset over 4 years ago

  • Target version changed from 5.0.16 to 5.0.17
Actions #12

Updated by Vincent MEMBRÉ about 4 years ago

  • Target version changed from 5.0.17 to 5.0.18
Actions #13

Updated by Vincent MEMBRÉ almost 4 years ago

  • Target version changed from 5.0.18 to 5.0.19
Actions #14

Updated by Vincent MEMBRÉ almost 4 years ago

  • Status changed from Pending technical review to New
Actions #15

Updated by Vincent MEMBRÉ almost 4 years ago

  • Target version changed from 5.0.19 to 5.0.20
Actions #16

Updated by Vincent MEMBRÉ over 3 years ago

  • Target version changed from 5.0.20 to 797
Actions #17

Updated by Benoît PECCATTE almost 3 years ago

  • Target version changed from 797 to 6.1.14
Actions #18

Updated by Vincent MEMBRÉ almost 3 years ago

  • Target version changed from 6.1.14 to 6.1.15
Actions #19

Updated by Vincent MEMBRÉ almost 3 years ago

  • Target version changed from 6.1.15 to 6.1.16
Actions #20

Updated by Vincent MEMBRÉ almost 3 years ago

  • Target version changed from 6.1.16 to 6.1.17
Actions #21

Updated by Vincent MEMBRÉ over 2 years ago

  • Target version changed from 6.1.17 to 6.1.18
Actions #22

Updated by Vincent MEMBRÉ over 2 years ago

  • Target version changed from 6.1.18 to 6.1.19
Actions #23

Updated by Alexis Mousset about 2 years ago

  • Status changed from New to Resolved

Solved through report_id instead of promiser stack.

Actions

Also available in: Atom PDF