Project

General

Profile

Actions

Bug #21431

open

Error with parameters expansion for node

Added by Nicolas Ecarnot over 2 years ago. Updated over 2 years ago.

Status:
New
Priority:
N/A
Assignee:
-
Category:
Techniques
Severity:
Major - prevents use of part of Rudder | no simple workaround
UX impact:
It bothers me each time
User visibility:
Operational - other Techniques | Rudder settings | Plugins
Effort required:
Priority:
64
Name check:
To do
Fix check:
To do
Regression:
No

Description

Hello,

I have created a custom technique [1] that is using a parameter (called " ${debiancodename} ").
I have created a directive that is using this technique, and for the parameter, I'm setting it the value : ${node.properties[codename]}
This property is set up by a hook script [2] that I'm deploying on each node and which is filling the codename property of each node.
I have created a rule that is using this directive, applying it on every nodes.

This is all working very well... except :

When adding a brand new node and joining it to the hub, the hook script is not copied yet, thus the property has not been declared yet, and the hub is crashing this way :

Jul 19 11:12:53 sit-conf-prd01 rudder[policy.generation]: [ERROR] Error while computing Node Configuration for nodes: ; cause was: Accumulated: Unexpected: Error with parameters expansion for node 'sit-webdelib-prd02.sitpi.lan' (eee23364-3b41-429d-9cfd-45b0df83d1ab); cause was: Accumulated: When processing directive 'sit - upgrade rudder agent (debian like)'; cause was: Accumulated: On variable 'F0C056EE-CD53-40D1-96F3-A55EDA15A9AE':; cause was: Accumulated: Unexpected: Missing property '${node.properties[codename]}' on node 'sit-webdelib-prd02.sitpi.lan' [eee23364-3b41-429d-9cfd-45b0df83d1ab]

leading to the policies generation failing, and the whole system stuck at this point.

I can manually workaround the situation using the following methods :
  • disable the node. Well, that makes the hub usable, but goes no further on the node...

or

  • disable the rule, wait for the hook script to get copied, wait for the hook script to get executed, thus the property gets declared, then I can re-enable the rule

I'm not sure the policies generation should be stuck by a single node failing its parameters expansion. In this case, this node could be ignored, and the rule could fail only for this node.

Thanks for reading this far.

Nicolas ECARNOT

[1]

{
  "type": "ncf_technique",
  "version": "3.0",
  "data": {
    "id": "sit___upgrade_rudder_agent__debian_like_",
    "version": "1.0",
    "name": "sit - upgrade rudder agent (debian like)",
    "description": "",
    "category": "ncf_techniques",
    "parameter": [
      {
        "id": "f0c056ee-cd53-40d1-96f3-a55eda15a9ae",
        "name": "debiancodename",
        "description": "" 
      }
    ],
    "calls": [
      {
        "component": "Command execution",
        "id": "143a8f57-c71f-4fdd-8850-189c481d04a5",
        "method": "command_execution",
        "condition": "",
        "parameters": [
          {
            "name": "command",
            "value": "rm -f /var/rudder/cfengine-community/state/packages_updates_*" 
          }
        ],
        "disableReporting": false
      },
      {
        "component": "File content",
        "id": "310198e5-fb0a-4a2d-87b2-325b665ccdb7",
        "method": "file_content",
        "condition": "",
        "parameters": [
          {
            "name": "path",
            "value": "/etc/apt/sources.list.d/rudder.list" 
          },
          {
            "name": "lines",
            "value": "deb http://repository.rudder.io/apt/latest/ ${debiancodename} main" 
          },
          {
            "name": "enforce",
            "value": "true" 
          }
        ],
        "disableReporting": false
      },
      {
        "component": "Package state",
        "id": "a97c677e-470b-4787-807d-e1588a752ec7",
        "method": "package_state",
        "condition": "",
        "parameters": [
          {
            "name": "name",
            "value": "rudder-agent" 
          },
          {
            "name": "version",
            "value": "latest" 
          },
          {
            "name": "architecture",
            "value": "" 
          },
          {
            "name": "provider",
            "value": "" 
          },
          {
            "name": "state",
            "value": "" 
          }
        ],
        "disableReporting": false
      }
    ],
    "resources": []
  }
}

[2]

# cat /var/rudder/hooks.d/get_codename.sh

#!/bin/sh
# Returns codename for debian/ubuntu distribs

codename=''
get_codename() {
    if [ -f /usr/bin/lsb_release ]; then
        codename=$(/usr/bin/lsb_release -cs)
        return 0
    fi
    if [ -f /etc/os-release ]; then
        codename=$(grep CODENAME /etc/os-release | cut -d '=' -f 2 | tail -n 1)
        return 0
    fi
}
get_codename
/bin/echo '{"codename": "'${codename}'"}'
Actions #1

Updated by Nicolas CHARLES over 2 years ago

Hi Nicolas,

There are several options for your issue
  • if there is a default value that you can use for the node property, you may use the syntax ${node.properties[codename] | default = "some default value" } , so that if the variable don't exist, a default is used (see https://docs.rudder.io/reference/6.2/usage/variables.html#_directive )
  • if you don't have a good default value to use, then you may force the evaluation on the node side ${node.properties[codename] | node } - the property should need to exist on the node itself, defined in a json file in /var/rudder/local/properties.d/*.json (see https://docs.rudder.io/reference/7.1/reference/variables.html#_technical_implementation_of_node_properties ). Note that if the variable is not defined on the node, the part of the policy using the variable will be skipped; so in your case, file /etc/apt/sources.list.d/rudder.list won't be created, but the rest of the technique will
I also have 2 remarks on your technique:
  • why don't you use this command to get the property within the technique itself ?
  • you are always deleting the package cache rm -f /var/rudder/cfengine-community/state/packages_updates_* , even if file /etc/apt/sources.list.d/rudder.list didn't change - so you are effectively defeating the concept of this caching, and puting an extra strain on your system. It would probably be better to delete the cache only if the rudder.list file was updated

Regards
Nicolas

Actions #2

Updated by Nicolas Ecarnot over 2 years ago

Nicolas CHARLES wrote in #note-1:

[...]
Nicolas

Thank you Nicolas for these advises. In some weeks I'll be able to try to apply them to our setup, so I'll be able to comment further on these points.

Best regards,

Nicolas ECARNOT

Actions #3

Updated by Nicolas CHARLES over 2 years ago

  • UX impact changed from I bothers me each time to It bothers me each time
  • Priority changed from 52 to 64
  • Regression set to No
Actions

Also available in: Atom PDF