Project

General

Profile

Actions

User story #3014

closed

Optionnal variables should not be nulled (if they are not system variables)

Added by Nicolas PERRON about 12 years ago. Updated over 9 years ago.

Status:
Released
Priority:
N/A
Category:
Web - Config management
Target version:
UX impact:
Suggestion strength:
User visibility:
Effort required:
Name check:
Fix check:
Regression:

Description

When we use an optionnal fields in Technique, there are two differents behaviour that are confusing :
  1. if there is only one value for this field, and it is empty, the generated value is a "null" (nothing)
  2. if there are several values for this fields, all the empty values are replaced by "" (empty string)

This lead to unexpected behaviour, as both are clearly different

We should clarify this behaviour, surely by having one "optional" field that replaced empty value by "" , and on that is replaced by null and that can't be multivalued

Under is a technical details of what happen on the technique generatin side
Using the same parameters than the files:
  • EnforceFileContentExpandVarBug1.png
  • EnforceFileContentExpandVarBug2.png

It will lead to a CFEngine promise generated without variable generic_file_content_modification_destination:

debian-5-64:~# grep 'generic_file_content_modification_destination' /var/rudder/cfengine-community/inputs/checkGenericFileContent/3.0/checkGenericFileContent.cf 
            "replacement_dest_defined_$(index)"  expression => isvariable("generic_file_content_modification_destination[$(index)]");
                    edit_line => set_arbitrary_file_content_modify("$(generic_file_content_modification_regexp[$(index)])", "$(generic_file_content_modification_destination[$(index)])"),
Adding a new Directive with the same parameters than the files:
  • EnforceFileContentExpandVarBug1.png
  • EnforceFileContentExpandVarBug1.png
debian-5-64:~# grep 'generic_file_content_modification_destination' /var/rudder/cfengine-community/inputs/checkGenericFileContent/3.0/checkGenericFileContent.cf 
            "generic_file_content_modification_destination[1]" string => "";
            "generic_file_content_modification_destination[2]" string => "";
            "replacement_dest_defined_$(index)"  expression => isvariable("generic_file_content_modification_destination[$(index)]");
                    edit_line => set_arbitrary_file_content_modify("$(generic_file_content_modification_regexp[$(index)])", "$(generic_file_content_modification_destination[$(index)])"),

It seems that this is linked to the application instead of the Techniques (#2819).


Files

EnforceFileContentExpandVarBug1.png (44.5 KB) EnforceFileContentExpandVarBug1.png Parameters of the Directive A 1/2 Nicolas PERRON, 2012-11-19 17:31
EnforceFileContentExpandVarBug2.png (50.8 KB) EnforceFileContentExpandVarBug2.png Parameters of the Directive A 2/2 Nicolas PERRON, 2012-11-19 17:31
EnforceFileContentExpandVarBug3.png (44 KB) EnforceFileContentExpandVarBug3.png Parameters of the Directive B 1/2 Nicolas PERRON, 2012-11-19 17:31
EnforceFileContentExpandVarBug4.png (50.1 KB) EnforceFileContentExpandVarBug4.png Parameters of the Directive B 2/2 Nicolas PERRON, 2012-11-19 17:31

Subtasks 1 (0 open1 closed)

User story #5303: Use empty ("") value in place of null for variable that has the attribute maybeemptyReleasedFrançois ARMAND2014-07-24Actions
Actions #1

Updated by Nicolas CHARLES about 12 years ago

Here, the issue is rather tricky.
The variable has the attribute MAYBEEMPTY. But a MAYBEEMPTY variable is set to null if : 1/ it is empty, and 2/ it has 0 or 1 element within

There is no way to define a variable that can be empty, but not replaced by null (or at least, it is not shown in the code), and I guess the use of the "MAYBEEMPTY" as drift a bit from it's original design

We should probably need to rewrite these techniques, or use a new attribgute to define variable that can be empty, but not replaced by null

Actions #2

Updated by Nicolas PERRON almost 12 years ago

  • Target version changed from 2.3.9 to 2.3.10
Actions #3

Updated by François ARMAND almost 12 years ago

  • Status changed from New to Discussion
  • Assignee set to Nicolas PERRON

Nicolas thinks it should be corrected. Please, could you check if that bug is not a duplicate ?

Actions #4

Updated by Nicolas PERRON almost 12 years ago

  • Target version changed from 2.3.10 to 2.5.0~beta1

François ARMAND wrote:

Nicolas thinks it should be corrected. Please, could you check if that bug is not a duplicate ?

This is not a duplicate, this is a bug related to the fact that MAYBEEMPTY could be empty or null as said Nicolas. It will neither be fixed in 2.3 nor in 2.4.

Actions #5

Updated by Nicolas PERRON almost 12 years ago

  • Assignee changed from Nicolas PERRON to Nicolas CHARLES
Actions #6

Updated by Nicolas PERRON almost 12 years ago

  • Target version changed from 2.5.0~beta1 to 2.5.0~rc1
Actions #7

Updated by François ARMAND almost 12 years ago

  • Status changed from Discussion to 8
Actions #8

Updated by François ARMAND almost 12 years ago

  • Tracker changed from Bug to User story
  • Target version changed from 2.5.0~rc1 to 2.6.0~beta1
Actions #9

Updated by Nicolas CHARLES almost 12 years ago

  • Subject changed from Using Enforce a File Content PT/Technique v3.0 with Replacement instruction and empty destination content could lead to bug to Using optionnal multivalued variables can lead to unexpected behaviour
  • Description updated (diff)
Actions #10

Updated by Nicolas PERRON over 11 years ago

  • Target version changed from 2.6.0~beta1 to 2.6.0~rc1
Actions #11

Updated by Matthieu CERDA over 11 years ago

  • Target version changed from 2.6.0~rc1 to 2.6.0
Actions #12

Updated by Jonathan CLARKE over 11 years ago

  • Target version changed from 2.6.0 to 2.6.1
Actions #13

Updated by Nicolas PERRON over 11 years ago

  • Target version changed from 2.6.1 to 2.6.2
Actions #14

Updated by Nicolas PERRON over 11 years ago

  • Target version changed from 2.6.2 to 2.6.3
Actions #15

Updated by Nicolas PERRON over 11 years ago

  • Target version changed from 2.6.3 to 2.6.4
Actions #16

Updated by Nicolas PERRON about 11 years ago

  • Target version changed from 2.6.4 to 2.6.5
Actions #17

Updated by Nicolas PERRON about 11 years ago

  • Status changed from 8 to Discussion
  • Assignee changed from Nicolas CHARLES to François ARMAND

François, why did you change this bug into an User Story ?

Actions #18

Updated by Nicolas PERRON about 11 years ago

  • Target version changed from 2.6.5 to 2.6.6
Actions #19

Updated by Nicolas PERRON about 11 years ago

  • Target version changed from 2.6.6 to 2.6.7
Actions #20

Updated by Nicolas PERRON about 11 years ago

  • Target version changed from 2.6.7 to 2.6.8
Actions #21

Updated by Nicolas PERRON about 11 years ago

  • Target version changed from 2.6.8 to 2.6.9
Actions #22

Updated by Nicolas PERRON about 11 years ago

  • Target version changed from 2.6.9 to 2.6.10
Actions #23

Updated by Vincent MEMBRÉ almost 11 years ago

  • Target version changed from 2.6.10 to 2.6.11
Actions #24

Updated by Vincent MEMBRÉ over 10 years ago

  • Target version changed from 2.6.11 to 2.6.12
Actions #25

Updated by Vincent MEMBRÉ over 10 years ago

  • Target version changed from 2.6.12 to 2.6.13
Actions #26

Updated by Vincent MEMBRÉ over 10 years ago

  • Target version changed from 2.6.13 to 2.6.14
Actions #27

Updated by Jonathan CLARKE over 10 years ago

  • Target version changed from 2.6.14 to 2.6.16
Actions #28

Updated by Jonathan CLARKE over 10 years ago

  • Target version changed from 2.6.16 to 2.6.17
Actions #29

Updated by Nicolas CHARLES over 10 years ago

  • Subject changed from Using optionnal multivalued variables can lead to unexpected behaviour to Optionnal variables should not be nulled (if they are not system variables)

For the moment, if we have a variable defined as MAYBEEMPTY, and no value is set, we have possibilities:
- only once is this variable defined (one instance of directive only), then it is null (the variable is NOT THERE in the generated promises)
- several times is this varialbe defined, then we have multiple "", "", ""

Actions #30

Updated by Nicolas CHARLES over 10 years ago

  • Status changed from Discussion to 13
  • Assignee changed from François ARMAND to Nicolas CHARLES
  • Target version changed from 2.6.17 to 140

So, we'll need to update the semantic, plus the technique ClockConfiguration, the only technique that rely on the nullable feature

Actions #31

Updated by Nicolas CHARLES over 10 years ago

Actually, there are no technique to update, they are all correctly written, with proper use of if with boolean , or non null variable

there would be a clean up of techniques that use isvariable though...

Actions #32

Updated by Nicolas CHARLES about 10 years ago

  • Status changed from 13 to Pending release

implementation is pending release, so correcting this ticket

Actions #33

Updated by Matthieu CERDA about 10 years ago

  • Target version changed from 140 to 3.0.0~beta1
Actions #34

Updated by Vincent MEMBRÉ almost 10 years ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 3.0.0~beta1 which was release on 01/12/2014.

Actions #35

Updated by Benoît PECCATTE over 9 years ago

  • Category changed from 14 to Web - Config management
Actions

Also available in: Atom PDF