Project

General

Profile

User story #10551

Make policy generation be node by node

Added by François ARMAND over 3 years ago. Updated about 1 year ago.

Status:
New
Priority:
N/A
Assignee:
-
Category:
Web - Config management
Suggestion strength:
Want - This would make my life a lot easier but I can manage without
User visibility:
Getting started - demo | first install | level 1 Techniques
Effort required:
Large

Description

We want to make the policy generation node by node, so that:

  • a faulty node does not block the policy generation for other nodes,
  • in case of very long generation (>30 min), we don't have to wait the whole time to have node starting to get new policy generation,
  • errors are reported on a node by node basis
  • we can have a meaningfull progress bar for the generation ("7 nodes out of 25"...)

This, of course, lead a number of questions, for example:

  • how do we manage dependencies (typically between a node and its policy server, if hostname change)? What happen if only one the the two updates breaks?
  • how do we make errors understandable and discoverable? Imagine if 7000 nodes are in error.

(and certainly a number of others).

Moreover, the parallelism of the policy generation can be more fine-grained controlled, along with the JS timeout, dynamic group computation at start of generation, and change computation with API:

# for max parallelism, either use '1x' to mean "1 time the number of CPU / 2" or '3' to mean '3 threads'
curl -k -H "X-API-Token: xxx"  -X POST 'https://.../rudder/api/latest/settings/rudder_generation_max_parallelism' -d "value=1x" 
# value is in seconds
curl -k -H "X-API-Token: xxx"  -X POST 'https://.../rudder/api/latest/settings/rudder_generation_js_timeout' -d "value=10" 
# use 'false' or 'true' 
curl -k -H "X-API-Token: xxx"  -X POST 'https://.../rudder/api/latest/settings/rudder_generation_compute_dyngroups' -d "value=false" 
curl -k -H "X-API-Token: xxx"  -X POST 'https://.../rudder/api/latest/settings/rudder_compute_changes' -d "value=false" 

Related issues

Related to Rudder - Bug #14465: Generation fails with "Task FutureTask rejected from ThreadPoolExecutor" due to timeout in JS computationReleasedFrançois ARMANDActions
#1

Updated by Benoît PECCATTE over 2 years ago

  • Target version set to Ideas (not version specific)
#2

Updated by François ARMAND about 1 year ago

  • Target version changed from Ideas (not version specific) to 5.0.12
#3

Updated by François ARMAND about 1 year ago

  • Status changed from New to In progress
  • Assignee set to François ARMAND
#4

Updated by François ARMAND about 1 year ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from François ARMAND to Nicolas CHARLES
  • Pull Request set to https://github.com/Normation/rudder/pull/2233
#5

Updated by Nicolas CHARLES about 1 year ago

One important point: once a node is generated, its policies are available, and its expected reports are also available (and considered as expected)
So if we generate the policy of a new node, and the policy generation is slow (like 15 minutes), and its policy server has its policy generated last, for 15 minutes the new nodes wont have its policy served to it, and it will be in "No Answer" for 15 minutes

#6

Updated by François ARMAND about 1 year ago

  • Description updated (diff)
#7

Updated by François ARMAND about 1 year ago

  • Related to Bug #14465: Generation fails with "Task FutureTask rejected from ThreadPoolExecutor" due to timeout in JS computation added
#8

Updated by François ARMAND about 1 year ago

  • Description updated (diff)
#9

Updated by François ARMAND about 1 year ago

  • Description updated (diff)
#10

Updated by Vincent MEMBRÉ about 1 year ago

  • Target version changed from 5.0.12 to 5.0.13
#12

Updated by François ARMAND about 1 year ago

  • Status changed from Pending technical review to New
  • Assignee deleted (Nicolas CHARLES)
  • Target version changed from 5.0.13 to Ideas (not version specific)

We won't do that in 5.0 nor in 5.1.

Also available in: Atom PDF